Seguin Posted January 6, 2020 Share Posted January 6, 2020 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 More sharing options...
doekia Posted January 6, 2020 Share Posted January 6, 2020 Cela vient du fait qu'une erreur c'est produite 1 Link to comment Share on other sites More sharing options...
Seguin Posted January 6, 2020 Author Share Posted January 6, 2020 Merci , ça on avait vu ! Mais encore : Link to comment Share on other sites More sharing options...
kokou z Posted January 6, 2020 Share Posted January 6, 2020 (edited) svp doekia, aidez nous à résoudre l'erreur Edited January 6, 2020 by kokou z (see edit history) Link to comment Share on other sites More sharing options...
Mediacom87 Posted January 6, 2020 Share Posted January 6, 2020 Erreur 500 = page blanche = affichage des erreurs : https://www.prestatoolbox.fr/content/24-messages-erreurs-prestashop Link to comment Share on other sites More sharing options...
kokou z Posted January 6, 2020 Share Posted January 6, 2020 Mediacom87,c'est qu'on arrive pas avoir accès au back office Link to comment Share on other sites More sharing options...
Mediacom87 Posted January 6, 2020 Share Posted January 6, 2020 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 : Utilisez votre client FTP habituel pour ouvrir votre fichier /config/defines.inc.php sur votre serveur d'hébergement Dans ce fichier passez à ON l'option display_errors remplace define('_PS_MODE_DEV_', false); par define('_PS_MODE_DEV_', true); Enregistrez votre fichier sur votre serveur Rafraichissez la page de votre site afin de mettre en évidence le message d'erreur 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 More sharing options...
kokou z Posted January 6, 2020 Share Posted January 6, 2020 oui je l'ai fait mais voici les erreurs Link to comment Share on other sites More sharing options...
Mediacom87 Posted January 6, 2020 Share Posted January 6, 2020 Il manque tout le haut, la partie sur fond rouge où se trouve des donnés capitales. Link to comment Share on other sites More sharing options...
Seguin Posted January 6, 2020 Author Share Posted January 6, 2020 Bonsoir,ci joint première page.. ci dessous premiere Link to comment Share on other sites More sharing options...
doekia Posted January 6, 2020 Share Posted January 6, 2020 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 Link to comment Share on other sites More sharing options...
Nono56b Posted January 6, 2020 Share Posted January 6, 2020 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. Link to comment Share on other sites More sharing options...
Seguin Posted January 7, 2020 Author Share Posted January 7, 2020 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 More sharing options...
doekia Posted January 7, 2020 Share Posted January 7, 2020 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 More sharing options...
Seguin Posted January 7, 2020 Author Share Posted January 7, 2020 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 More sharing options...
Seguin Posted January 7, 2020 Author Share Posted January 7, 2020 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 More sharing options...
doekia Posted January 7, 2020 Share Posted January 7, 2020 Un RAM disque de 168K en guise de /tmp ?? c'est n'importe quoi Link to comment Share on other sites More sharing options...
Seguin Posted January 8, 2020 Author Share Posted January 8, 2020 Bonsoir, Nous avons vérifié le serveur et voici la vraie valeur: /dev/loop0 2.6G 49M 2.4G 3% /tmp Link to comment Share on other sites More sharing options...
Seguin Posted January 8, 2020 Author Share Posted January 8, 2020 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 More sharing options...
Seguin Posted January 8, 2020 Author Share Posted January 8, 2020 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 More sharing options...
Seguin Posted January 8, 2020 Author Share Posted January 8, 2020 Les inodes contiennent notamment les métadonnées des fichiers, et en particulier celles concernant les droits d'accès. Link to comment Share on other sites More sharing options...
doekia Posted January 8, 2020 Share Posted January 8, 2020 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 More sharing options...
Seguin Posted January 9, 2020 Author Share Posted January 9, 2020 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 More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now