Pour un OS multi-utilisateurw c'est le comportement "standard" qui est aberrant.
Sur une machine d'université (pour prendre un pire cas), si chaque personne qui se connecte sur l'ordinateur a un processus persistant à vie, il faut redémarrer la machine tous les trois jours.
La manière de faire peut-être discutable, mais à moins de prendre Windows, il n'existe pas D'API pour exprimer ce genre de besoins.
Et non daemonize n'exprime pas la persistance sur une session. Il exprime juste l'indépendance avec le shell appelant.
Par exemple, en situation difficile je fais des nohup firefox&, qui a la même sémantique que daemonize.
Fort heureusement dans ce cas, la notion de session est définie par X, et je fais confiance à firefox pour se suicider quand il perd le serveur X.
Aussi, systemd garantit de connaître la liste des processus persistants, alors que la sémantique de daemonize ne le permet pas.
Bref, comme d'hab avec systemd, on peut éventuellement reprocher le manque de documentation, et encore, cf le commentaire "NEWS", mais systemd apporte une vraie avancée technique.
[^] # Re: Bug ferme chez tmux
Posté par Ph Husson (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 10.
Pour un OS multi-utilisateurw c'est le comportement "standard" qui est aberrant.
Sur une machine d'université (pour prendre un pire cas), si chaque personne qui se connecte sur l'ordinateur a un processus persistant à vie, il faut redémarrer la machine tous les trois jours.
La manière de faire peut-être discutable, mais à moins de prendre Windows, il n'existe pas D'API pour exprimer ce genre de besoins.
Et non daemonize n'exprime pas la persistance sur une session. Il exprime juste l'indépendance avec le shell appelant.
Par exemple, en situation difficile je fais des nohup firefox&, qui a la même sémantique que daemonize.
Fort heureusement dans ce cas, la notion de session est définie par X, et je fais confiance à firefox pour se suicider quand il perd le serveur X.
Aussi, systemd garantit de connaître la liste des processus persistants, alors que la sémantique de daemonize ne le permet pas.
Bref, comme d'hab avec systemd, on peut éventuellement reprocher le manque de documentation, et encore, cf le commentaire "NEWS", mais systemd apporte une vraie avancée technique.