Il m'arrive de temps en temps — la première fois sur le serveur, du moins que je le constate — que la RAM rapportée par la commande free -h et sur Proxmox soit différente de ce qui est rapporté sur htop. Pourtant, le conteneur est à court de RAM dans le sens où l'OOM killer¹ est invoqué pour terminer un processus.

Le symptôme

La différence des chiffres sur l'hyperviseur, la commande free et htop ne permet pas vraiment de voir plus clair. htop affiche une consommation plus élevée (si je me rappelle, ça fait un moment que l'idée de cet article traîne). On pourrait presque dire que la mémoive vive est remplie de données de Schrödinger².

La réponse — et le déclic — est dans la sortie de la commande df -h: le point de montage /run dont le système de fichiers est tmpfs est plein. La différence entre free et htop s'explique que free ne compte pas l'espace occupé par /run.

Ce qui occupe l'espace libre

Le paramètre Storage de systemd-journald est réglé sur auto. Selon le manuel journald.conf(5) (traduit de l'anglais)

"auto" se comporte comme "persistent" si le dossier /var/log/journal existe, et "volatile" autrement (l'existence du dossier contrôle le mode de stockage)

Comme /var/log/journal n'existait pas, journald est allé ranger son journal dans /run/log/journal comme si Storage était réglé sur volatile. Comme le système de fichiers tmpfs utilise de la RAM pour stocker ce qu'on lui confie, il est logique qu'il a fini par ne plus avoir d'espace et, par conséquent, causé quelques ennuis aux processus déjà en exécution.