Vous vous souvenez peut-être de mon post blâmant journald qui polluait mes logs et remplissait /var/log ? (http://ban.netlib.re/shaarli/?RVgspw) Bon et bien j'avais assez tort, ce n'est pas directement la faute de systemd en fait (ça passe par lui, mais ce n'est pas sa faute).

Ce qui remplit /var/log c'est juste syslog, qui écrit les logs de journald sur le disque (et les écrit trois fois, je n'ai pas cherché pourquoi). Quoi qu'il en soit ça fait longtemps que syslog fait ça, mais ça n'a pas grande incidence car peu d'applications logguent via syslog.

Le vrai problème est que les développeurs de GDM ont imaginé que c'était une bonne idée que de logguer la sortie de la session X explicitement via journald au lieu du bon vieux .xsession-errors (ou de $XDG_CACHE_HOME/gdm/session.log dans les versions plus récentes de GDM). Ça a l'air gentillet dit comme ça, mais ça envoie beaucoup de choses dans jounrald, qui sous Debian les renvoie à syslog, qui les écrit sur le disque.

Bref, maintenant il faut attendre que ce problème soit corrigé dans Debian. Pour ça il y a probablement deux solutions :

1. Ne pas écrire dans journald les entrées de GDM. Ça a l'air assez simple, puisque GDM semble avoir une option de compilation pour ça, justement prévue pour les systèmes qui renvoient journald à syslog.
2. Ne pas écrire dans syslog les entrées que GDM écrit via journald. C'est peut-être malin (utiliser journald pour écrire un journal n'est peut-être pas idiot -- encore que, vu quel la sortie de la session X n'est pas vraiment un journal) mais requiert probablement une conf syslog ou journald spéciale que je ne connais pas.

(3. ne pas utiliser GDM. Là le problème est qu'avec par exemple lightdm certaines choses fonctionnent moins bien (au moins sous MATE, mais je pense que ce sera pareil sous GNOME), comme les mises en veilles/reboot/changement d'utilisateurs/délock depuis le DM, etc.)

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.