Tu installes un nouveau service, tu sais direct comment t'en servir, et notamment que tu peux avoir ses logs en lançant journalctl -fu service par exemple. grep, tail, tout ça, tu peux continuer à les utiliser en apprenant une commande : journalctl -u service; c'est pas la mort. En général il y a un flag pour faire ça mieux direct dans l'outil, mais c'est toujours possible.
Ou pas. Genre tiens mon service "zefklop" a pas démarré (ou si?). Faisons juste un ps ax | grep zefklop. oula non. systemctl status zefklop parcequ'on est moderne:
octane@patate:~ $ systemctl status zefklop
●くろまる zefklop.service - On-premise tartiflette AI powered (multi-instance-master)
Loaded: loaded (/lib/systemd/system/zefklop.service; enabled; preset: enabled)
Active: active (exited) since Tue 2025年02月18日 17:20:32 GMT; 14h ago
Process: 302473 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Main PID: 302473 (code=exited, status=0/SUCCESS)
CPU: 6ms
Feb 18 17:20:32 patate systemd[1]: Starting zefklop.service - tartiflette On-premise
Feb 18 17:20:32 patate systemd[1]: Finished zefklop.service - tartiflette On-premise
Bien bien bien. Du coup on a "active (exited)" Ca veut dire quoi? code=exited status=SUCCESS? Donc il a démarré, mais il est arrêté?
Bah non, tout faut, zefklop.service c'est un lien sur /bin/true (pourquoi? parceque fuck you, that's why!!) et qu'il fallait utiliser systemctl start zefklop@default t'avais qu'a lire la doc! (wut?). Et t'as de la couleur dans le terminal! Et va pas faire un tail /var/log/messages parcequ'il est vide, lol! systemd c'est modulaire, mais faut prendre tout le package complet sinon ça marche moins bien.
Cette standardisation, ça demande effectivement un apprentissage initial, mais sur le long terme, c'est moins la pagaille, l'ensemble est plus facile à comprendre et au final c'est moins d'effort.
Ouais. Comme tail, grep, cat, et quelques autres outils utilisés universellement ailleurs. C'est effectivement un apprentissage initial (c'est quoi déjà le -x de journalctl? ou c'est -u, ou attends je suis au travers d'un xterm dans un VNC et journalctl a gentiment mis de la couleur et du scroll à droite/gauche sauf que du coup j'ai pas la fin de la ligne).
C'est toujours un plaisir de passer 2h à chercher de la doc pour apprendre l'existence d'une option assez obscure et mystérieuse qui fait exactement ce que tu veux faire dans un cas précis d'usage (car systemd sait ce qui est bon pour toi). Tu mets l'option, ça marche de manière assez mystérieuse, et tu t'empresses de l'oublier. Learn once, use once, forget immediately. Ca me rappelle l'époque héroïque de windows quand on te disait d'aller manipuler des clés dans la base de registre avec des valeurs opaques. Des fois ça marchait bien. J'ai du utiliser l'autre jour "ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
" Je suis heureux de savoir que ce genre de directive existe. C'est très utile.
Je vais me faire moinsser encore une fois, mais vous connaisser le sketch du tailleur de Fernand Reynaud? https://www.youtube.com/watch?v=TtADuXkM560 bah je crois que c'est un peu ça le principe. Tu fais tout comme systemd veut que tu fasses, t'es content. Tu veux faire légèrement différent, il ne reste qu'à te tordre en deux pour faire à la manière de systemd et tu seras content. Ca va toujours pas? Bah t'as toujours rien compris, tu te tiens mal et tu fais mal, fais comme systemd veut et tords toi encore un peu et ça sera bien.
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par octane . En réponse au lien 14 ans de systemd. Évalué à -2.
Ou pas. Genre tiens mon service "zefklop" a pas démarré (ou si?). Faisons juste un ps ax | grep zefklop. oula non. systemctl status zefklop parcequ'on est moderne:
Bien bien bien. Du coup on a "active (exited)" Ca veut dire quoi? code=exited status=SUCCESS? Donc il a démarré, mais il est arrêté?
Bah non, tout faut, zefklop.service c'est un lien sur /bin/true (pourquoi? parceque fuck you, that's why!!) et qu'il fallait utiliser systemctl start zefklop@default t'avais qu'a lire la doc! (wut?). Et t'as de la couleur dans le terminal! Et va pas faire un tail /var/log/messages parcequ'il est vide, lol! systemd c'est modulaire, mais faut prendre tout le package complet sinon ça marche moins bien.
Ouais. Comme tail, grep, cat, et quelques autres outils utilisés universellement ailleurs. C'est effectivement un apprentissage initial (c'est quoi déjà le -x de journalctl? ou c'est -u, ou attends je suis au travers d'un xterm dans un VNC et journalctl a gentiment mis de la couleur et du scroll à droite/gauche sauf que du coup j'ai pas la fin de la ligne).
C'est toujours un plaisir de passer 2h à chercher de la doc pour apprendre l'existence d'une option assez obscure et mystérieuse qui fait exactement ce que tu veux faire dans un cas précis d'usage (car systemd sait ce qui est bon pour toi). Tu mets l'option, ça marche de manière assez mystérieuse, et tu t'empresses de l'oublier. Learn once, use once, forget immediately. Ca me rappelle l'époque héroïque de windows quand on te disait d'aller manipuler des clés dans la base de registre avec des valeurs opaques. Des fois ça marchait bien. J'ai du utiliser l'autre jour "ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
" Je suis heureux de savoir que ce genre de directive existe. C'est très utile.
Je vais me faire moinsser encore une fois, mais vous connaisser le sketch du tailleur de Fernand Reynaud? https://www.youtube.com/watch?v=TtADuXkM560 bah je crois que c'est un peu ça le principe. Tu fais tout comme systemd veut que tu fasses, t'es content. Tu veux faire légèrement différent, il ne reste qu'à te tordre en deux pour faire à la manière de systemd et tu seras content. Ca va toujours pas? Bah t'as toujours rien compris, tu te tiens mal et tu fais mal, fais comme systemd veut et tords toi encore un peu et ça sera bien.