Diagnostiquer les erreurs système qui font crash les services

Maintenir la stabilité de leurs systèmes et services sous Ubuntu est un défi pour nous, petits administrateurs système. Que ce soit par passion sur votre temps libre pour votre site internet et votre application Laravel, mais aussi dans un cadre purement professionnel. Ici, je vais reprendre les bases donc si vous êtes un administrateur aguerri, vous avez sûrement déjà mis en place des solutions de monitoring bien plus puissances que d’aller regarder ce qu’il se passe directement dans le serveur.

J’avais néanmoins envie de faire cet article, car je pense qu’il peut servir à tout le monde et notamment pour aider les débutants. J’ai un petit serveur web chez Digital Ocean qui fonctionnait bien depuis des années sans le moindre problème avec plusieurs WordPress dessus. Sauf que depuis quelque temps, les problèmes ont commencé. Dans mon cas et c’est ce qui m’a amené à faire la rédaction de cet article pour vous aider à dépanner vous aussi votre serveur web sous Linux Ubuntu / Debian.

Tout allait donc dans le meilleur des monde avec la stack classique PHP / MariaDB et NGINX, mais récemment, j’ai eu plusieurs crashs de service. Cela faisait tomber l’ensemble des sites sur le serveur, et ce, de manière totalement aléatoire. J’ai bien évidemment commencé à regarder ce qu’il se passait avec l’utilisation de l’outil monitoring htop, mais je ne voyais rien de particulier et il était de toute façon trop tard. Je voyais juste à la limite que le service qui avait planté n’était plus là, mais ça je savais déjà plus ou moins. Je cherche à avoir la cause avec des erreurs explicites.

Pour ne vraiment rien arrange, mon problème, c’est ce que le service qui crashait était aléatoire. Aléatoire dans le temps et aussi sur le programme qui était concerné. Un coup, c’était le service PHP-FPM, une autre fois, c’était le service MariaDB. Il est temps d’enquêter.

Le journal de log système sur Ubuntu / Debian

Pour savoir ce qu’il se passe on va donc aller voir ce qu’il y a dans le fichier : /var/log/syslog. Les logs c’est vraiment très utile. Heureusement dans Linux c’est facilement accessible et lisible par défaut pour essayer de résoudre le problème que vous rencontrez.

Vous trouverez dans ce fichier /var/log/syslog une variété d’informations, y compris des messages liés au démarrage du système, des messages d’erreurs d’applications, ainsi que des alertes de sécurité et des messages de diagnostic.

Vous pouvez bien évidemment ouvrir ce fichier directement avec votre éditeur de texte préféré et le parcourir pour trouver la raison de vos problèmes. Dans mon cas, j’ai déjà identifié les services qui plantent et ce sont toujours les mêmes. Je vais une nouvelle fois utiliser la commande grep pour aller chercher les informations qui m’intéressent. Pour ce faire, je commence avec MariaDB et vous pouvez de votre côté adapter selon votre problème. J’utilise donc simplement un grep comme ceci :

sudo grep mariadb /var/log/syslog

En y regardant de plus prêt, je tombe alors sur le groupe de ligne qui m’intéresse plus précisément :

Feb  4 21:37:58 ubuntu-WP-5 kernel: [616181.942029] Out of memory: Killed process 719 (mariadbd) total-vm:1088732kB
Feb  4 21:37:58 ubuntu-WP-5 systemd[1]: mariadb.service: A process of this unit has been killed by the OOM killer.
Feb  4 21:37:58 ubuntu-WP-5 systemd[1]: mariadb.service: Main process exited, code=killed, status=9/KILL
Feb  4 21:37:58 ubuntu-WP-5 systemd[1]: mariadb.service: Failed with result 'oom-kill'.
Feb  4 21:37:58 ubuntu-WP-5 systemd[1]: mariadb.service: Consumed 5min 1.145s CPU time.

C’est plutôt intéressant ça non ? On peut dire que la raison de mon problème est assez explicite. Maintenant pour être sûr que la cause à mes problèmes et commune, je vais regarder du côté de PHP avec la même commande grep :

sudo grep php /var/log/syslog

Cette fois, j’obtiens un nouveau résultat qui confirme rapidement mon hypothèse :

Feb  7 17:01:42 ubuntu-WP-5 kernel: [193856.295751] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=php8.2-fpm.service,mems_allowed=0,global_oom,task_memcg=/system.slice/php8.2-fpm.service,task=php-fpm8.2,pid=31635,uid=33
Feb  7 17:01:42 ubuntu-WP-5 kernel: [193856.295772] Out of memory: Killed process 31635 (php-fpm8.2)

À la lecture de ces erreurs, j’ai donc pendant quelques secondes des mini pic de charge que mon serveur n’arrive pas absorber par manque de mémoire vive. J’ai alors remarqué que mon espace swap ne faisait pas correctement son rôle, depuis que j’ai modifié sa configuration tout est rentré dans l’ordre et je n’ai plus de problèmes.

Grâce à ces commandes simples, j’ai donc pu rapidement identifier la cause du problème via les logs de ma distribution Linux et trouver la correction à appliquer. Bien évidemment, il y a de grandes chances pour que le problème soit différent chez vous, mais c’était pour mettre en évidence comment chercher facilement dans les logs. J’espère que ça vous aidera à maintenant vos serveurs sous Linux Ubuntu / Debian et que vous pourrez facilement trouver les modifications à faire pour résoudre votre problème.