C'est un fonctionnement simpliste qui permet à n'importe qui de créer des daemons
Ça n'est pas compliqué mais de la a dire que c'est "simpliste", faut pas exagèrer, hein. D'ailleurs ce sont deux concepts orthogonaux.
Le concept de daemon n'implique pas un traitement particulier de la session et des terminaux et réciproquement. On peut avoir un daemon controleur de session, ou pas contrôleur, avec un terminal, ou sans terminal. Un "daemon" est de ce fait une notion assez floue et qui dans le sens commun s'entend comme "tourne en arrière plan" (tourne == pas en tant que zombie...) mais sans impliquer d'autres comportements plus précis en ce qui concerne, p.e. la gestion de la session[1].
Effectivement, il y a des interactions et des changements d'états implicites avec la création/mort des processus, qu'il peut-être utile de comprendre pour ne pas se tirer une balle dans le pied. Bref dire que le hup sert à créer des daemons c'est comme dire que le klaxon sert écraser les piétons... Par exemple, ce screen/tmux qui nous occupe pour l'instant car il est sensé tourner en arrière-plan sans discontinuer (aux dernières nouvelles c'est un peu le sujet de la discussion, c'est un peu pourquoi on en est venu à dévier sur nohup) ne fonctionne pas du tout de la même façon qu'un programme lancé avec nohup même si, in fine, ils survivent tout deux à une rupture du terminal.
Pour info, HUP ça veut dire "hang up" et c'est le nom du signal que le noyau envoit au fameux "session leader" lorsqu'il détecte une perte sur la ligne du TTY "contrôleur". Ces histoires de tty controleur et de session est une relique de UNIX (enfin je crois que les sessions sont arrivées un peu plus tard avec BSD, la flemme d'aller vérifier), un gros hack qui s'est transformé en standard. Tout cela est bien documenté, il suffit de lire la doc, je ne ferrai pas l'affront de passer pour un "gouroux", on peut bien sûr discuter de la météo :D
Cette histoire de killer tous les users process, c'est un peu comme réinventer ce hack. Mais en encore plus crade car il n'y a plus de notion de session (enfin si, il parait que ça s'appelle logind et que ça sert à changer les ACL d'un fichier dans /dev/drm... pour ce que j'en ai compris) et donc pas de solution pour faire coopérer les programmes (on attend toujours le patch qui merge libdbus dans la glibc ... :p et bye bye musl, uclib (ah non ça s'était déja fait))
C'est un peu retourner à l'ère des teletypes avec pour seul moyen pour se déconnecter que de tirer la fiche série...
Pour en revenir au sujet, pas la peine de se sentir idiot pour constater 1) c'est systemd qui a mis en avant un autre comportement assez surprenant 2) les empaqueteur debian ont peut-être mal évalué (ou ne se sont pas rendus compte de) la porté d'un tel changement 3) systemd reste une valeur trollifère sûre, au moins tout le monde est au courant; voir certains en font un argument marketing (cf. https://kaosx.us/news/2016/june/ )
Mon avis sur systemd (pour continuer un peu le trolll^W^Wla discussion) c'est que c'est à la fois trop et trop peu. Trop peu car j'ai un peu l'impression que c'est juste le produit d'une lubie pour faire jou-jou avec la dernière technique à la mode mais malheureusement sans profondes remises en questions ou innovations quant à la manière de concevoir un systèmes. Les avantages mis en avants sont souvent de l'ordre technique (ex. "pas de fuite possible de daemon", oui et ? moi j'ai jamais eu de daemon qui "fuite") voir rhéthorique (ex. "la classe tout le monde est dans son cgroup", mais maintenant, concrètement, qu'est-ce que je peux faire avec ?). Aussi paradoxalement, les techniques d'implémentations et les choix de conceptions sont décevants. À savoir: quantité importante de code dans un langage "unsafe", comportement difficilement explicable/non déterministe, API trop volatile/non-spécifiée, documentation imprécise et incomplète, dépendance sur d'autres composants et tous les problèmes qui vont avec (dbus), nécessite toujours un noyau récent, support déficient des montées en version sans rebooter (i.e. systemd est sensé sérialiser son état, mettre à jour son binaire puis recharger son état mais ça ne fonctionne pas très bien), flexibilité/configuratibilité très limitée, parti pris de ne pas vouloir être porté sur d'autre OS[2]... Conséquences de vouloir être ce "trop". En plus, il s'immisce partout, veut devenir une sorte d'API de-facto pour administrer un système: logind, timed, dbus, etc.
Sans finalement apporter de réelles avancées, il ne justifie pas, à mon sens, un tel coût.
Finalement, je constate que la rapprochement avec la guerre des unix est fort pertinent.
[1]: La fonction daemon est donc un cas particulier avec un comportement spécifique suffisant pour certains ou inacceptable pour d'autres. N'est pas daemon uniquement celui qui appelle daemon(), elle n'est d'ailleurs pas spécifée par POSIX (AFAICT).
[2]: le plus drôle dans cette histoire c'est que la personne à l'origine de cette décision, Lennart pour le nommer, justifie (et assume) cette décision avec un argument idéologico-politique. I.e. quand il dit "unix est mort, il s'appelle Linux" on est en plein dans le discours d'idées. C'est un comble de faire l'apologie d'une perfection (appelons un chat un chat) et en même temps de se refuser un moyen peu coûteux et avéré pour améliorer la qualité de son produit. Mais bon on a jamais pris de bonnes décisions en étant dogmatique... :p
[^] # Re: systemd, le nouveau Multics
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 8.
Ça n'est pas compliqué mais de la a dire que c'est "simpliste", faut pas exagèrer, hein. D'ailleurs ce sont deux concepts orthogonaux.
Le concept de daemon n'implique pas un traitement particulier de la session et des terminaux et réciproquement. On peut avoir un daemon controleur de session, ou pas contrôleur, avec un terminal, ou sans terminal. Un "daemon" est de ce fait une notion assez floue et qui dans le sens commun s'entend comme "tourne en arrière plan" (tourne == pas en tant que zombie...) mais sans impliquer d'autres comportements plus précis en ce qui concerne, p.e. la gestion de la session[1].
Effectivement, il y a des interactions et des changements d'états implicites avec la création/mort des processus, qu'il peut-être utile de comprendre pour ne pas se tirer une balle dans le pied. Bref dire que le hup sert à créer des daemons c'est comme dire que le klaxon sert écraser les piétons... Par exemple, ce screen/tmux qui nous occupe pour l'instant car il est sensé tourner en arrière-plan sans discontinuer (aux dernières nouvelles c'est un peu le sujet de la discussion, c'est un peu pourquoi on en est venu à dévier sur nohup) ne fonctionne pas du tout de la même façon qu'un programme lancé avec nohup même si, in fine, ils survivent tout deux à une rupture du terminal.
Pour info, HUP ça veut dire "hang up" et c'est le nom du signal que le noyau envoit au fameux "session leader" lorsqu'il détecte une perte sur la ligne du TTY "contrôleur". Ces histoires de tty controleur et de session est une relique de UNIX (enfin je crois que les sessions sont arrivées un peu plus tard avec BSD, la flemme d'aller vérifier), un gros hack qui s'est transformé en standard. Tout cela est bien documenté, il suffit de lire la doc, je ne ferrai pas l'affront de passer pour un "gouroux", on peut bien sûr discuter de la météo :D
Cette histoire de killer tous les users process, c'est un peu comme réinventer ce hack. Mais en encore plus crade car il n'y a plus de notion de session (enfin si, il parait que ça s'appelle logind et que ça sert à changer les ACL d'un fichier dans /dev/drm... pour ce que j'en ai compris) et donc pas de solution pour faire coopérer les programmes (on attend toujours le patch qui merge libdbus dans la glibc ... :p et bye bye musl, uclib (ah non ça s'était déja fait))
C'est un peu retourner à l'ère des teletypes avec pour seul moyen pour se déconnecter que de tirer la fiche série...
Pour en revenir au sujet, pas la peine de se sentir idiot pour constater 1) c'est systemd qui a mis en avant un autre comportement assez surprenant 2) les empaqueteur debian ont peut-être mal évalué (ou ne se sont pas rendus compte de) la porté d'un tel changement 3) systemd reste une valeur trollifère sûre, au moins tout le monde est au courant; voir certains en font un argument marketing (cf. https://kaosx.us/news/2016/june/ )
Mon avis sur systemd (pour continuer un peu le trolll
^W^Wla discussion) c'est que c'est à la fois trop et trop peu. Trop peu car j'ai un peu l'impression que c'est juste le produit d'une lubie pour faire jou-jou avec la dernière technique à la mode mais malheureusement sans profondes remises en questions ou innovations quant à la manière de concevoir un systèmes. Les avantages mis en avants sont souvent de l'ordre technique (ex. "pas de fuite possible de daemon", oui et ? moi j'ai jamais eu de daemon qui "fuite") voir rhéthorique (ex. "la classe tout le monde est dans son cgroup", mais maintenant, concrètement, qu'est-ce que je peux faire avec ?). Aussi paradoxalement, les techniques d'implémentations et les choix de conceptions sont décevants. À savoir: quantité importante de code dans un langage "unsafe", comportement difficilement explicable/non déterministe, API trop volatile/non-spécifiée, documentation imprécise et incomplète, dépendance sur d'autres composants et tous les problèmes qui vont avec (dbus), nécessite toujours un noyau récent, support déficient des montées en version sans rebooter (i.e. systemd est sensé sérialiser son état, mettre à jour son binaire puis recharger son état mais ça ne fonctionne pas très bien), flexibilité/configuratibilité très limitée, parti pris de ne pas vouloir être porté sur d'autre OS[2]... Conséquences de vouloir être ce "trop". En plus, il s'immisce partout, veut devenir une sorte d'API de-facto pour administrer un système: logind, timed, dbus, etc.Sans finalement apporter de réelles avancées, il ne justifie pas, à mon sens, un tel coût.
Finalement, je constate que la rapprochement avec la guerre des unix est fort pertinent.
[1]: La fonction daemon est donc un cas particulier avec un comportement spécifique suffisant pour certains ou inacceptable pour d'autres. N'est pas daemon uniquement celui qui appelle daemon(), elle n'est d'ailleurs pas spécifée par POSIX (AFAICT).
[2]: le plus drôle dans cette histoire c'est que la personne à l'origine de cette décision, Lennart pour le nommer, justifie (et assume) cette décision avec un argument idéologico-politique. I.e. quand il dit "unix est mort, il s'appelle Linux" on est en plein dans le discours d'idées. C'est un comble de faire l'apologie d'une perfection (appelons un chat un chat) et en même temps de se refuser un moyen peu coûteux et avéré pour améliorer la qualité de son produit. Mais bon on a jamais pris de bonnes décisions en étant dogmatique... :p