Jump to content
Seguin

Backoffice inaccessible

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

Share this post


Link to post
Share on other sites

Cela vient du fait qu'une erreur c'est produite

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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.

 

 

Share this post


Link to post
Share on other sites

Il manque tout le haut, la partie sur fond rouge où se trouve des donnés capitales.

Share this post


Link to post
Share on other sites

Bonsoir,ci joint première page..

image.thumb.png.b72de37e797cadf74105b17b8bc26256.pngci dessous premiere 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Bonsoir,

Si prestashop 1.7, peut être commencer par supprimer les répertoires présents dans  \var\cache (prod et dev).

Ils seront reconstruit automatiquement.

 

Share this post


Link to post
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

 

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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.

 

 

Share this post


Link to post
Share on other sites

Un RAM disque de 168K en guise de /tmp ?? c'est n'importe quoi

Share this post


Link to post
Share on other sites

Bonsoir,

Nous avons vérifié le serveur et voici la vraie valeur:

/dev/loop0 2.6G 49M 2.4G 3% /tmp

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

Les inodes contiennent notamment les métadonnées des fichiers, et en particulier celles concernant les droits d'accès.

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More