My concern is that we have a little function, daemon(), that does a simple little procedure to make a daemon that has worked basically unchanged across multiple platforms for maybe, what, 30 years?
Je vos nul part que cette fonction permet le background même si l'utilisateur se déconnecte.
donc je ne vois pas en quoi systemd "casse" quelque chose, je dirai plutôt qu'un développeur a vu un comportement, s'est pas embêté à regarder la doc et a imaginé que ça serait toujours pareil.
Et en fait, comme c'est mis dans les autres commentaires, ça semble être juste une option de systemd à changer, rien d'horrible juste une politique par défaut (et comme d'autres, je trouve que tuer tous les process qui n'ont pas dit explicitement qu'ils veulent rester quand on se déconnecte et qui n'ont pas été autorisés à le faire, ce n'est pas forcément une mauvaise idée, ce n'est pas "mais les salauds pensent pas comme moi", les deux options ont des avantages et inconvénients).
Sinon pour le journal :
Sauf que depuis une récente mise à jour de ma Debian sur mon poste utilisateur, j'ai mon tmux qui est tué lorsque je me déconnecte (tmux est censé continuer à travailler en arrière plan).
Si c'est pas une tache système (mis en user), pourquoi un utilisateur déconnecté devrait continuer à avoir des process qui bouffent du CPU? il peut rester connecté aussi, ça permet d'ailleurs d'associer un processus à une session utilisateur (et de "tuer" cette session et ces process si ça consomme trop).
Finalement, quelle utilité de se déconnecter?
Ca me semble un faux problème.
[^] # Re: Bug ferme chez tmux
Posté par Zenitram (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à -2.
man daemon
Je vos nul part que cette fonction permet le background même si l'utilisateur se déconnecte.
donc je ne vois pas en quoi systemd "casse" quelque chose, je dirai plutôt qu'un développeur a vu un comportement, s'est pas embêté à regarder la doc et a imaginé que ça serait toujours pareil.
Et en fait, comme c'est mis dans les autres commentaires, ça semble être juste une option de systemd à changer, rien d'horrible juste une politique par défaut (et comme d'autres, je trouve que tuer tous les process qui n'ont pas dit explicitement qu'ils veulent rester quand on se déconnecte et qui n'ont pas été autorisés à le faire, ce n'est pas forcément une mauvaise idée, ce n'est pas "mais les salauds pensent pas comme moi", les deux options ont des avantages et inconvénients).
Sinon pour le journal :
Si c'est pas une tache système (mis en user), pourquoi un utilisateur déconnecté devrait continuer à avoir des process qui bouffent du CPU? il peut rester connecté aussi, ça permet d'ailleurs d'associer un processus à une session utilisateur (et de "tuer" cette session et ces process si ça consomme trop).
Finalement, quelle utilité de se déconnecter?
Ca me semble un faux problème.