L'idée d'utiliser un signal, c'est bien pour signaler que le processus est prêt. SI on le fait sans vraiment savoir ( iequand on a lancé mais qu'on a pas vraiment vérifié ), on reviens à ce que ferait un gestionnaire de processus sans notification.
Le coup de ne pouvoir surveiller que son fils, c'est sans
utiliser les cgroup, hors, systemd l'utilise justement.
Je suis pas spécialiste des cgroups, mais waitid ( qui est utilisé par upstart pour choper l'état d'un fils ) n'est pas lié avec les cgroups. La façon dont systemd utilise les cgroups, c'est juste pour grouper les process et les limiter. Et il se sert du second pour la répartition des ressources, et du premier comme un liste de soft à tuer avec une boucle. Les primitives unix ne permettent pas autre chose, sauf erreur de ma part ( ie, surveiller un processus arbitraire, sauf via ptrace, ce qui pose un autre type de souci, et ptrace qui est utilisé justement aussi par upstart, avec aussi une implémentation avec un certain nombre de souci dans son design )
Et même, pourquoi n'exec-t-il pas erl ?
ça oui, c'est la solution théorique, et je suis d'accord qu'idéalement, c'est ce qu'il faut faire. Ensuite, il y a la pratique, et dans la pratique, il y a des options pour que ça n'arrive pas ( dans le cas de.
Bon, il a peut-être des raisons, et le coup du SIGSTOP peut
effectivement sembler bidouille dans ce cas.
Et c'est le souci. Le SIGSTOP semble séduisant pour un daemon simple, mais pour un daemon simple, il y a pas de souci.
Et ça deviens compliqué assez vite pour les programmes non triviaux, programmes non triviaux qui justement bénéficient d'autant plus de la notification car ils font plein de choses avant d'être prêt.
L'avantage du protocole de systemd, c'est qu'il est transparent si c'est fait comme il faut. sd_notify est une non opération si il n'est pas lancé avec les variables qui vont bien. Donc pas de souci de doc, pas d'interférence avec un usage ( bien que ça soit un souci d'ordre très théorique, j'ai passé du temps à voir en pratique ce qui l'utilise chez debian et j'ai trouvé surtout des softs pour utilisateur plus que système, donc le souci est pas non plus trés bloquant, on peut reconnaitre ça )
[^] # Re: Mini précision, variable d'environnement
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 6. Dernière modification le 24 janvier 2014 à 01:10.
L'idée d'utiliser un signal, c'est bien pour signaler que le processus est prêt. SI on le fait sans vraiment savoir ( iequand on a lancé mais qu'on a pas vraiment vérifié ), on reviens à ce que ferait un gestionnaire de processus sans notification.
Je suis pas spécialiste des cgroups, mais waitid ( qui est utilisé par upstart pour choper l'état d'un fils ) n'est pas lié avec les cgroups. La façon dont systemd utilise les cgroups, c'est juste pour grouper les process et les limiter. Et il se sert du second pour la répartition des ressources, et du premier comme un liste de soft à tuer avec une boucle. Les primitives unix ne permettent pas autre chose, sauf erreur de ma part ( ie, surveiller un processus arbitraire, sauf via ptrace, ce qui pose un autre type de souci, et ptrace qui est utilisé justement aussi par upstart, avec aussi une implémentation avec un certain nombre de souci dans son design )
ça oui, c'est la solution théorique, et je suis d'accord qu'idéalement, c'est ce qu'il faut faire. Ensuite, il y a la pratique, et dans la pratique, il y a des options pour que ça n'arrive pas ( dans le cas de.
Et c'est le souci. Le SIGSTOP semble séduisant pour un daemon simple, mais pour un daemon simple, il y a pas de souci.
Et ça deviens compliqué assez vite pour les programmes non triviaux, programmes non triviaux qui justement bénéficient d'autant plus de la notification car ils font plein de choses avant d'être prêt.
L'avantage du protocole de systemd, c'est qu'il est transparent si c'est fait comme il faut. sd_notify est une non opération si il n'est pas lancé avec les variables qui vont bien. Donc pas de souci de doc, pas d'interférence avec un usage ( bien que ça soit un souci d'ordre très théorique, j'ai passé du temps à voir en pratique ce qui l'utilise chez debian et j'ai trouvé surtout des softs pour utilisateur plus que système, donc le souci est pas non plus trés bloquant, on peut reconnaitre ça )