GuiGui's Show

Sur l'un de mes serveurs informatiques Debian GNU/Linux stable, la commande who n'affiche rien. La commande w n'affiche pas plus les utilisateurs connectés. Ça fait plus d'un an et demi que ça dure. Dans le passé, j'ai eu ce comportement avec des conteneurs LXC et uniquement des conteneurs LXC. Mais ce système n'a jamais été dans un conteneur. Je me décide à étudier un peu le problème.

TL;DR : sudo chown root:root /.

Évidemment, rien dans les journaux systèmes usuels (avec le mot-clé « utmp »).

Le premier résultat dans un moteur de recherche web est la base de connaissances de Suse : 'who' output is blank, returns nothing. De même, le manuel d'utmp est clair : « None of these programs creates the file, so if it is removed, record-keeping is turned off ». Sur mon serveur, le fichier /var/run/utmp n'existe pas. En le créant, who (et w) affiche toutes les connexions SSH postérieures.

L'ennui, c'est que /var/run est un lien vers /run, et que /run est un tmpfs (c'est-à-dire un ramdisk, stocké en mémoire vive). Donc son contenu sera effacé au prochain redémarrage (ou extinction). C'est la config par défaut de Debian.

L'hypothèse la plus probable est qu'un logiciel ne crée pas le fichier /var/run/utmp au démarrage de la machine ou le crée trop tôt, quand le tmpfs n'est pas encore monté.

L'absence de création peut être liée à une absence de configuration. Mais, une comparaison de la sortie de grep -Ri utmp /etc entre plusieurs machines montre une config identique.

Quel logiciel s'occupe de créer /var/run/utmp ? Je soupçonne systemd. Je regarde la liste des units avec systemctl list-units. Tiens, systemd-update-utmp.service. Je redémarre ce service : le fichier est toujours absent.

Une recherche sur le web désigne systemd-tmpfiles. systemctl status systemd-tmpfiles-setup.service affiche « (code=exited, status=73) » et « Detected unsafe path transition / (owned by guigui) → /run (owned by root) during canonicalization of XXXX ». Même chose pour /var. Sur mes autres machines (serveurs ou non), le code retour est 0, et il n'y a aucune erreur.

Tout s'éclaircit : il y a encore un an et demi, ce système était une machine virtuelle chez un autre hébergeur. J'ai exposé la migration ici. Le support de stockage de destination était un disque dur externe raccordé en USB utilisant le système de fichiers ext4. Pour l'utiliser sans les droits root, j'avais donc changé le propriétaire du point de montage, et donc celui de la racine du système de fichiers (en clair : sudo chown guigui /mnt/disqueDurExterne). Et, en effet, ls -la sur le serveur (qui utilise ledit disque dur) expose que / appartient à guigui au lieu de root.

Je rétablis les droits corrects : sudo chown root:root /.

Je redémarre mon serveur. systemd-tmpfiles-setup.service termine son boulot sans erreur (code retour = 0), et who (et w) affiche les utilisateurs connectés. \o/