Erreurs 500

De VK Wiki
Aller à : navigation, rechercher

De temps en temps, il arrive qu'au lieu d'avoir une page web attendue, on obtient une erreur 50X (501, 502, 503, etc.) Ces erreurs sont assez rares, mais sont bloquantes lorsqu'elles arrivent, il est donc important de les corriger rapidement, d'autant qu'elles bloquent en général tout un serveur, et non juste un site.


Voici quelques trucs qui peuvent aider à résoudre ce genre d'erreur :

Espace disque saturé

La plupart des services fonctionnant sur un serveur web sont fiables, il est très rare qu'elles plantent du fait d'un bug, et en général une erreur 500 est due au fait qu'un des services a fait face à un bloquant. Un des premiers bloquants à vérifier, c'est si un service n'essaie pas d'écrire sur un espace disque saturé.


La première chose à vérifier, c'est l'espace disque restant sur toutes les partitions[1]

df -h

On obtient alors une liste d'éléments ressemblant à la liste ci-dessous :

FilesystemSizeUsedAvailUse%Mounted on
/dev/dm-08.2G972M6.8G13% /
udev10M010M0%/dev
tmpfs99M4.6M95M5%/run
tmpfs248M0248M0%/dev/shm
tmpfs5.0M05.0M0%/run/lock
tmpfs248M0248M0%/sys/fs/cgroup
/dev/mapper/web--vg-tmp360M2.1M335M1%/tmp
/dev/mapper/web--vg-var2.7G2.6G0M100%/var
/dev/sda1236M33M191M15%/boot
/dev/mapper/web--vg-home27G1.3G25G6%/home


Il faut alors porter son attention aux lignes indiquant une utilisation de 100% (avant dernière colonne). Une ligne à 100% indique un disque plein, sur lequel le système ne peut plus écrire, ce qui provoque une erreur. La dernière colonne de cette ligne indique le répertoire correspondant à cette partition.

Dans l'exemple ci-dessus, il s'agit de la ligne du répertoire /var

/dev/mapper/web--vg-var2.7G2.6G0M100%/var

Cela veut dire que l'espace contenu dans le répertoire /var est saturé, il va donc falloir continuer à chercher les sources du problèmes dans ce répertoire.

Pour ce faire, on utilise l'instruction du[2] qui affiche la taille des répertoires, avec l'opérateurs -h (human readable) pour rendre le résultat plus facile à lire. Il est possible d'ajouter l'opérateur --max-depth=1 pour réduire l'affichage aux répertoires de 1er niveau (sans les sous-répertoires).

du -h --max-depth=1 /var

4.0K/var/local
210M/var/cache
115M/var/lib
64K/var/spool
4.0K/var/tmp
24K/var/mail
16K/var/lost+found
16K/var/www
4.0K/var/opt
1.5M/var/backups
2.3G/var/log
378M/var

Dans le cas ci-dessus, on voit que le répertoire /var/log prend beaucoup de place. Cela veut dire que des applications ont enregistré des journaux en grande quantité, il s'agit en général de mySQL et de NGINX, la première chose est donc de supprimer ces journaux et ensuite de régler ces applications afin qu'elles enregistrent moins de données et/ou qu'elles les enregistrent dans un autre endroit.

Suppression et réglages des logs de Nginx

Pour supprimer les journaux de NGINX, une simple commande rm * en tant que super-utilisateur, à l'intérieur du répertoire /var/log/nginx

Ensuite, le réglage de la journalisation se fait au niveau des fichiers de configuration de NGINX. Par défaut la configuration de la journalisation de NGINX se situe dans le fichier /etc/nginx/nginx.conf et est applicable à tous les sites web. Il s'agit des lignes :

error_log /var/log/nginx/error.log warn;

et

log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"';''

access_log /var/log/nginx/access.log main;

Pour une meilleure maintenabilité, il est recommandé d'enregistrer les journaux associés à chaque site séparément des autres ; cela évite d'avoir les informations de tous les sites dans un même fichier, ce qui rend les recherches assez fastidieuses en cas de problèmes. On peut donc recopier les lignes ci-dessus (sans la ligne log_format qui ne peut être utilisée ailleurs) dans les fichiers de configuration de chaque site, en les adaptant.

Par exemple, le site StephanH (extrait du fichier /etc/nginx/sites-available/stephanh.conf)

server {

listen 80;
listen [::]:80;
server_name stephanh.dev.groupehuot.com;


#Répertoire dans lequel il faut chercher les fichiers Web
root /var/www/html/stephanh.com;

#Répertoire contenant les logs
error_log /home/www/stephanh.com/log/error.log warn
access_log /home/www/stephanh.com/log/access.log main;


# Ajouter index.php à la liste lorsque l’on utilise PHP
index index.php index.html index.htm index.nginx-debian.html;
(...)


Il est possible de réduire la sensibilité[3][4] de la journalisation des erreurs, à l'aide de l'une des valeurs suivantes, de la plus critique à la plus détaillée (et moins significative) : emerg, alert, crit, error, warn, notice, info, debug

La valeur par défaut est warn (warning), qui indique tous les événements plus importants qu'un avertissement (incident qui peut poser problème mais ne provoque pas de plantage)


Le journal d'accès (access_log) est en général assez volumineux puisqu'il enregistre toutes les requêtes http (GET, PUT, POST... - affichage d'une page web, envoi de données...), il est très important de le placer dans un répertoire assez grand. Les formats (il peut y en avoir plusieurs) de ce journal ne peuvent être définis que dans le fichier nginx.conf à l'aide de l'instruction log_format[5] pour être ensuite utilisés au niveau de la configuration de chaque site.

Suppression et réglages des logs de mariaDB

La journalisation de mariaDB est sensiblement plus compliquée que celle de NGINX, car elle se fait sous forme binaire, et non sous forme de fichiers textes. Cette journalisation binaire est très volumineuse car elle enregistre toute requête effectuée dans une base ; c'est en quelques sortes un duplicata de la base en plus gros, car elle contient toutes les informations permettant de recréer une base à l'identique. Cette journalisation n'a que peu d'intérêt car le meilleur moyen de sauvegarder une base de données, est de le faire sur une autre machine, soit par un processus de sauvegarde, soit en regroupant deux serveurs dans une ferme (cluster).

Pour commencer, il faut supprimer les journaux existants. Pour cela, il faut se connecter à mariaDB en tant qu'adminstrateur

mysql -uroot -p

Saisir le mot de passe de l'administrateur et valider

Dans l'interface de la base de données, saisir l'instruction RESET MASTER;[6][7]

Quitter l'interface mySQL/mariaDB à l'aide de l'instruction quit


Ensuite il faut désactiver la journalisation de mariaDB. Pour ce faire, ouvrir le fichier /etc/mysql/my.cnf et commenter (en plaçant un signe dièse # devant la ligne) les lignes

log_bin = /var/log/mysql/mariadb-bin
log_bin_index = /var/log/mysql/mariadb-bin.index
sync_binlog = 1
expire_logs_days = 2
max_binlog_size = 100M

Puis redémarrer mySQL/mariaDB :

service mysql restart

Remarque : par défaut, mySQL installe sur le disque /var/ ce qui risque de provoquer les mêmes erreurs. Dans le script d'installation des serveurs, une série d'instructions déplace le répertoire des données.



  1. https://en.wikipedia.org/wiki/Df_(Unix)
  2. https://en.wikipedia.org/wiki/Du_(Unix)>
  3. https://www.digitalocean.com/community/tutorials/how-to-configure-logging-and-log-rotation-in-nginx-on-an-ubuntu-vps
  4. https://www.nginx.com/resources/admin-guide/logging-and-monitoring/
  5. http://nginx.org/en/docs/http/ngx_http_log_module.html#log_format
  6. https://mariadb.com/kb/en/mariadb/sql-commands-purge-logs/
  7. https://mariadb.com/kb/en/mariadb/reset-master/