Une investigation rapide dans les logs du serveur de messagerie montrent que l’antivirus (clamd) consommant de plus en plus de mémoire a déclenché la colère de l’OOM-Killer et a provoqué l’arrêt de « postfix » !

La même mésaventure est arrivée à un de mes clients, il y a quelques jours : « Dites : vous pouvez jeter un coup d’oeil à nos batchs (crontabs) car ils ne sont pas déclenchés ?« . La syntaxe semble pourtant bonne, les jobs, lancés manuellement, fonctionnent. Oui, mais voilà, le démon crond n’existe pas, pourtant il est bien lancé au démarrage… Que s’est-il passé ? La faute à l’OOM-Killer encore une fois !

Petit rappel de la gestion de la mémoire par le noyau Linux…

Fonctionnement du noyau Linux :

Un noyau Linux peut allouer plus de mémoire qu’il n’en possède vraiment (RAM + swap) :

par exemple, lors d’un fork, il y a copie virtuelle des pages de données. Tant que les processus ne les modifient pas, elles ne sont pas dupliquées (copy on write). On peut aussi expliquer le choix du noyau Linux par l’argument suivant « je peux accepter d’allouer de la mémoire pour le processus P car je sais qu’il ne va pas l’utiliser tout de suite. Et quand il voudra l’utiliser, avec de la chance, un autre processus en aura libérée« . C’est ce qu’on nomme un algorithme « optimiste » !

Mais même en étant optimiste, il arrive que la mémoire soit saturée : le noyau doit bien tenir ses promesses !

Un algorithme appelé OOM-Killer est alors invoqué pour tuer des processus (presque pris au hasard !) et ainsi récupérer de la mémoire.

Dans les cas cités plus haut, ce choix du « processus à dézinguer » est tombé sur smtpd (postfix) et crond… Oups ! Et heureusement que ce n’est pas tombé sur sshd !

Comment modifier l’algorithme de l’OOM-Killer ?

• tout d’abord le paramètre /proc/sys/vm/panic_on_oom (0 par défaut) peut recevoir la valeur 1 : dans ce cas, la machine se met en mode « panic », mode qui se règle aussi…
• le paramètre /proc/sys/vm/overcommit_memory peut recevoir la valeur 2 pour inhiber l’algorithme d’allocation optimiste, avec le risque de saturer la mémoir plus rapidement…

Comment protéger certains processus contre l’OOM-Killer ?

• pour chaque processus, le paramètre /proc/<PID>/oom_score donne la probabilité d’être éradiqué par l’OOM-Killer. Plus basse est la valeur, plus faible est cette probabilité. La valeur 0 indique un processus qui ne sera pas tué
• pour chaque processus, le paramètre /proc/<PID>/oom_adj permet d’adjuster cette probabilité. Le paramètre prend une valeur entre -17 et +15. La valeur -17 protège le processus contre l’OOM-Killer. A votre avis, quelle est la valeur attribuée à sshd ?

Conclusion :

• Surveiller le taux d’occupation de la mémoire (RAM et swap)
• Surveiller les logs pour vérifier que l’OOM-Killer ne s’est pas déclenché

1. le système de fichiers peut être saturé : il n’y a plus assez de data-blocks de libres ? (df -h)
2. vous utilisez un éditeur qui crée un fichier temporaire et il n’y a plus d’inodes de libre ? (df -i)
3. une erreur est survenue dans le système de fichiers et la configuration de celui-ci a provoqué un « remount-ro« , avez-vous vérifié les logs ? (tune2fs -l /dev/sdX vous permet de consulter le comportement du système de fichiers en cas d’erreur, less /var/log/messages)
4. rappelez-vous qu’il y a 6 mois vous avez placé l’attribut « immutable » sur le fichier /etc/hosts ! (lsattr /etc/hosts)
5. vous êtes en mode « rescue » ou « single user » et le système de fichiers racine est toujours monté en lecture seule ? (mount)

Avec un octet on ne fait pas grand-chose, on ne stocke presque rien. Rapidement, les fabricants de matériel ont fourni des mémoires, des disquettes, des disques pouvant contenir des milliers, des millions d’octets. Naturellement, ils ont réutilisé les multiples déjà en vigueur, à savoir le kilo, le méga, etc…

On a vu apparaitre alors le Ko (kilo-octets) et le Mo (méga-octets)…. seulement, les informaticiens aimant les puissances de deux, le kilo-octets (Ko) des informaticiens ne faisait pas 1000 octets mais 1024 octets, car c’est la puissance de deux la plus proche de 1000 (1024 = 2 puissance 10). Dans le même esprit, le méga-octets faisait 2 ** 20 octets, soit 1.048.576 octets et non pas un million d’octets.

Les informaticiens ont donc réutilisé le kilo pour indiquer un multiple de 1024 alors que d’habitude un kilo signifie 1000 quelque chose (kilomètre, kilogramme…).

Pourquoi pas ? On s’est bien adapté…

Mais en 1998 l’International Electrotechnical Commission (IEC) a décidé qu’il fallait clarifier la situation. Ainsi de nouvelles unités ont été créées :

• le Kio qu’on prononce « kibi-octets » fait 1024 octets
• le Mio qu’on prononce « mébi-octets » fait 1024 * 1024 = 1.048.576 octets
• de même pour le Gio (gibi-octets – on ne rit pas !), le Tio (tébi-octets), etc…

Résumons : 1 Ko = 1000 octets alors que 1 Kio = 1024 octets

Quel est alors le problème ? Il est double :

1. tout d’abord, les manuels de vos outils informatiques, de vos commandes (fdisk, parted, …) ont-ils été mis à jour ? Quand vous lisez « Go » dans une page de doc, s’agit-il vraiment du multiple de 1000 ou bien est-ce toujours le multiple de 1024 qui est sous-entendu ? En général, en l’absence de mise à jour, les docs parlent en « multiples de 1024″
2. par contre, les constructeurs de disque ne se trompent pas eux : quand vous achetez un disque sur lequel on vous promet 1 To de stockage, il faut bien comprendre 10 puissance 12 octets et non pas 2 puissance 40 octets ! On final, vous vous retrouvez avec 931 Mio environ ! On vous aura prévenu : ne criez pas à l’arnaque…quoique….