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.