tl;dr: make sure libpam-systemd is installed (and that UsePAM is enabled in SSHd's configuration).

Today I wanted to add basic monitoring to a VM I run for work, and I set up munin-node for it -- there's already other VMs using it in the environment, so it's just adding that missing one. However, the users plugin gives bogus data: it always says there's 0 users logged in, which is obviously incorrect. A very quick look at the plugin tells me it leverages the who command. And indeed, that command also fails to list any logged-in users -- which is quite puzzling when you do this from an interactive SSH shell.

I looked up the issue in the web, leading me to a few Debian bugs, some of which seemed interesting: things about utmp being removed from some systemd version (because of year-2038 issues it seems), but reading through suggests it should be fixed in the version I have. Looking some more suggests it's systemd's fault for not supporting utmp, which indeed doesn't report the UTMP flag (systemctl --version). However, checking another VM I have shows that the same versions of coreutils (home of who) and systemd (still without UTMP) do work in that one. Meh? I ended up checking the difference in which packages were installed on both systems, and one package catch my eye: libpam-systemd is present on the working VM but not the failing one. Bingo: installing it solves the problem immediately.

The reason why it wasn't installed is because the VM bootstrap code does not install recommended packages, and libpam-systemd is only recommended by openssh-server and systemd-sysv, it's not a dependency.

I also had been bitten by a similar issue with systemctl not working for non-root (for a custom Munin plugin), which was due to missing DBus, because systemd itself only recommends default-dbus-system-bus. That one was easier to solve, because some people actually did mention the issue I saw was likely due to not having dbus properly running on the machine.

[edit] GuiGui reached out because he had similar issues (see his Debian 12 to 13 upgrade notes, section last, lastlog, wtmp), yet had libpam-systemd installed. It turns out he had disabled UsePAM in SSHd's configuration, which unsurprisingly renders installation of libpam-systemd irrelevant. If you're in the same situation, either enable PAM there (with the attached bagage), or use a workaround like he did.

Apparemment déjà quelqu'un s'est dit que c'était malin de mettre les logs de Xsession (donc que qu'on avait dans ~/.xsession-errors) dans /var/log/{messages,syslog,user.log}. Oui, les trois tant qu'à faire.
Enfin bref, déjà ça avait pas l'air super malin dit comme ça, mais quid de quand une application lancée par la session part en vrille et affiche tout un tas de bousin dans stderr ? Sans surprise, ces trois fichiers grossissent à vue d'œil.
Les miens ont atteint 320M chacun avant que je ne trouve et tue le programme incriminé (et encore, je m'en suis rendu compte dans la minute), ce qui m'a bouffé à peu de choses près 1G dans /var (je n'ai pas de /var, donc dans /). Et même si je n'ai pas vérifié, je pense que vu que le logger (journald) est un service système, il va avoir tous les droits pour utiliser les blocs réservés et donc remplir le FS à s'en rendre malade.
Ah le bon vieux temps où une telle chose n'aurait rempli "que" $HOME…

Enfin bref, le plus intéressant dans l'histoire est que si j'en crois la documentation de journald.conf, le comportement par défaut est de ne pas logguer les sessions avec le système. Mais ma conf de journald (celle par défaut dans Debian testing/unstable) est vide (tout est commenté) et devrait j'imagine utiliser les valeurs par défaut… enfin bref j'ai tenté de définir manuellement SplitMode=uid, on verra ce que ça donne.

Bref, je ne sais pas à qui revient vraiment la faute (journald tout pourri ou mauvaise conf dans Debian ?), mais le résultat est le même, mes logs on été pourris par une application bénigne en userspace qui est partie en vrille (comme le font et vont le faire les apps userspace). Et quid d'un petit malin qui fait ça exprès.

La suite (peut-être) au prochain numéro.