Jump to content

Backoffice inaccessible


Seguin

Recommended Posts

Bonjour,

Depuis Samedi 4 janvier nous n'avons plus accès à notre Backoffice il nous renvoi comme erreur :

Quand on essaye d'y accéder avec le compte administrateur :

"Oups! Une erreur s'est produite
Le serveur a renvoyé une "500 erreur de serveur interne".
Quelque chose est cassé. Veuillez nous indiquer ce que vous faisiez lorsque cette erreur s'est produite. Nous le corrigerons dès que possible. Désolé pour tout inconvénient causé."

Hors nous n'avons fait aucune mis à jour, nous n'avons pas changé d’hébergeur et notre certificat SSL est à jour....Les autres sites sur notre hébergeur en Wordpress n'on aucun probleme...D’où cela peut t'il venir ?

Merci de vos réponses

Link to comment
Share on other sites

il y a 3 minutes, kokou z a dit :

Mediacom87,c'est qu'on arrive pas avoir accès au back office

Je devine à votre réponse que vous utilisez la version 1.7 et surtout que vous n'avez pas pris le temps de lire les informations transmises et que je dois donc le faire à votre place :

 

Citation

 

Si vous n'avez pas accès au backoffice :

  1. Utilisez votre client FTP habituel pour ouvrir votre fichier /config/defines.inc.php sur votre serveur d'hébergement
  2. Dans ce fichier passez à ON l'option display_errors
  3. remplace define('_PS_MODE_DEV_', false);
  4. par define('_PS_MODE_DEV_', true);
  5. Enregistrez votre fichier sur votre serveur
  6. Rafraichissez la page de votre site afin de mettre en évidence le message d'erreur
  7. Si vous ne comprenez pas le message d'erreur alors rendez-vous sur le forum officiel de Prestashop pour demander de l'aide.

 

 

Link to comment
Share on other sites

MERCI,

on a deux sites Prestashop avec le même code erreur et les mêmes erreurs de script dont le backoffice est devenue inaccessible en même temps  chez le même hébergeur  Planete hoster avec les mêmes codes erreur...On continue les recherches ..

Ludovic

 

Link to comment
Share on other sites

Il y a 2 heures, Seguin a dit :

On continue les recherches ..

 

Il y a 15 heures, doekia a dit :

probablement que le répertoire temporaire /tmp ou autre selon votre hébergeur est soit inexistant, soit mauvais droits dessus

Commencez par faire vérifier cela par votre hébergeur

c'est bien de poser des questions, mais encore mieux de lire les réponses

Link to comment
Share on other sites

On a lu et on a même contacté notre hébergeur :

Voici le courrier envoyé :

"on a deux sites Prestashop hébergés chez vous qui ne nous permettent plus d’accéder au Backoffice et c'est arrivé en même temps. Apres debugage on s’aperçoit qu'ils ont les mêmes erreur à la virgule prêt. N'y a t'il pas un problème sur le répertoire temporaire /tmp ou autre chez vous qui pourrait être soit inexistant ou les droits aurait changé dessus.
Les deux sites qui ont généré les mêmes scripts d'appel en erreur sont : https://neoafrica.fr et https://acheterlivrer.africa"

Vous voyez on tient compte de vos  remarques on attend sa réponse avant d'agir

Link to comment
Share on other sites

Tout est réparé :

Cela venait en effet du dossier /tmp qui avait 100% d'inode.

[root@hybrid1603 ~]$ df -hTi
Filesystem Type Inodes IUsed IFree IUse% Mounted on
devtmpfs devtmpfs 975K 365 975K 1% /dev
tmpfs tmpfs 978K 8.9K 969K 1% /dev/shm
tmpfs tmpfs 978K 893 977K 1% /run
tmpfs tmpfs 978K 16 978K 1% /sys/fs/cgroup
/dev/sda1 xfs 60M 451K 60M 1% /
/dev/loop0 ext3 168K 168K 0 100% /tmp
tmpfs tmpfs 978K 1 978K 1% /run/user/0

J'ai vidé le répertoire.

J'ai ensuite procédé à la mise à jour de MariaDB vers la version 10.3 qui est plus performante et recommandée.

Tout fonctionne désormais, la page de connexion est accessible.

Merci a tout le monde.

 

 

Link to comment
Share on other sites

 

Bonsoir,

L'espace disque et les innodes sont différents.

Les innodes ne peuvent être modifiés et cela est le nombre total de fichiers.

ce qui n'est pas normal que le /tmp se remplisse  de fichiers sans que ceux-ci soi effacés par la suite automatiquement.

L S

Link to comment
Share on other sites

Merci pour votre réponse.
Effectivement : tmpFS (Temporary File System) est un système de fichiers Unix temporaire. Tout fichier créé dans un tel système de fichiers disparaît lors de l'arrêt du système.
Et effectivement, ce qui n'est pas normal c'est que le /tmp se remplisse de fichiers sans que ceux-ci soi effacés par la suite automatiquement
"Pour le moment tout est beau:"
Mais jusqu’à quand ?
Cordialement
Ludovic

Link to comment
Share on other sites

Houla la la ... beaucoup de "fausse" compréhensions ici.

Les inodes sont les tables des vecteurs des blocs associées aux fichiers rien a voir avec des meta-données

Un répertoire temporaire limité à 2.6G n'a aucune chance de fonctionner. Cet espace est utilisé notamment pour les tables temporaires MySQL dépassant les limites réglées tmp_table_size, max_heap_table_size, sachant que certaines tables temporaires peuvent être massive. Cet espace est par ailleurs utilisé par les sessions, et toutes sorte d'autre fichier temporaire.

En règle générale, sauf cas très spécifiques, un /tmp en RAM disk est une mauvaise solution.

Il est anormal que vos fichiers temporaires ne se nettoient pas. Mais il faut aussi depuis les version 1.7 que vous "purgiez" par cron vos sessions "perdues". C'est normalement mis en place par tout admin système qui se respecte. Si cela manque, en effet vous pourriez avec un nombre impressionnant de celles-ci.

Link to comment
Share on other sites

Bonjour

Effectivement  la taille de celui est  faible, mais nous avons aussi  crée un volume tmpfs sur le serveur.
Nous envisageons d'augmenter la taille jusqu’à 16 .

Et c'est quoi la  meilleures solutions qu'un /tmp en RAM disk ?

Merci

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...