Du coup, comme un processus ne peut surveiller que son fils, il se passe quoi dans le cas d'un soft comme le dit couchdb qui fait pas forcément un exec à la fin ( ie, le cas très précis de couchdb avec l'option pour relancer automatiquement le soft quand il se gauffre, cf /usr/bin/couchdb ) ?
Soit le script fait le SIGSTOP mais il va faire ça avant que couchdb soit prêt, soit erl le fait, mais personne ne va le surveiller.
Je n'ai peut-être pas capté un truc, mais pourquoi ne fait-il pas le SIGSTOP après ? Le coup de ne pouvoir surveiller que son fils, c'est sans utiliser les cgroup, hors, systemd l'utilise justement. Et même, pourquoi n'exec-t-il pas erl ? Bon, il a peut-être des raisons, et le coup du SIGSTOP peut effectivement sembler bidouille dans ce cas.
Et on peut généraliser le cas avec apache, php-fpm. Du coup, le code passe de "je fait raise(sigstop) + un if" à "je mets en place un canal de comm entre le fils et moi pour que le fils me signal son état, et que moi ensuite je fasse un SIGSTOP pour signaler à mon propre père.
OK, merci de l'explication sur les désavantages, je comprends mieux. À la base, je disais juste que l'excuse de « le coup du SIGSTOP est pourri car upstart le fait mal » me semblait en légère. Je suis d'accord du coup que ça n'est pas forcément le mieux.
Je ne suis pas sur qu'il soit sage d'user d'un argument de ce genre sans avoir fait un minimum de vérification et vérifier avant de supposer.
Rho, c'était pas une attaque ad hominem, c'était juste pour dire que ta remarque « c'est super facile de rajouter une dépendance » ne sera peut-être pas acceptée par tous les développeurs : oui, quand tu connais, c'est plus ou moins facile, mais en général les devs upstream ont besoin de faire appel à des empaqueteurs aguerris pour les aider à gérer tout ce bordel. Ça n'est pas pour rien que tout le monde peste contre les autotools : ils ne sont pas facile à aborder. (je ne dis pas qu'ils sont mauvais, au contraire : je suis même en train d'écrire une doc sur mon expérience dessus)
Quant à ton nick, oui, je sais que tu n'es pas un débutant, je fréquente linuxfr depuis un bout de temps quand même... ne le prend pas personnellement.
Si il y a que ça, tu peux aussi prendre les fichiers .c et .h prévu pour ça depuis le code de systemd. Moi, je trouve ça dégeu, mais si upstream insiste à pas rajouter de lien, c'est son code.
J'espère que ça peut être aussi facile que tu le dis. Vu l'inter-dépendance de tous les morceaux de systemd, je me permets d'avoir un petit doute, mais comme je n'ai pas regardé, je ne protesterais pas plus que ça.
Encore une fois, il y a 2 logiciels dans tout debian qui supporte le dit protocole.
Ah ? Merde, j'aurais dû vérifier, je pensais que c'était plus courant /o\
2) rajouter le support sur les milliers de paquets en question 3) patcher la documentation des milliers de paquets.
Note que ces points deux et trois sont aussi valables avec systemd.
Ensuite, c'est pas comme si Debian avait déjà fait des milliers de patchs pour tout un tas de trucs ( GFDL et la DGSF, le portage sur le Hurd, le portage pour kfreebsd ). C'est pas comme si les packageurs de Fedora ou d'autres distros doivent régulièrement faire des patchs pour tel nouvelle version de gcc ou tel options de gcc, tel lib qui a été mise à jours et qui changent 2/3 trucs.
Oui, mais dans ce que tu cites, c'est souvent soit pour enlever des trucs, soit pour adapter du code existant. L'ajout de dépendance sur un autre logiciel, pas prévu au début pour le programme, ça rentre pour moi quand même dans une catégorie un peu plus pointue de travail et potentiellement d'emmerdes. Mais bon, si ça permet d'améliorer la gestion de démons du système, ça mettra peut-être plus de motivation dans le cœur des empaqueteurs...
Enfin, je continue à dire qu'il n'y a pas vraiment besoin de rajouter de protocole de notification pour la plupart des softs. Il y a plus d’intérêt à faire du on-demand avec les sockets par exemple.
Perso, je trouverais ça pratique avec des softs qui ont des comportements pas facile à gérer pour moi ; typiquement, qui offrent un socket de contrôle, mais qui est créé après que l'exécutable se soit démonisé. Typiquement, dans le monde réel, ça passe, mais en VM ça va tellement vite que mes scripts d'init doivent kludger (sleep...) pour que ça marche. C'est pour ça que si systemd prend bien, et que le travail colossal pour l'intégrer est fait, je trouverai ça bien au final.
[^] # Re: Mini précision, variable d'environnement
Posté par benoar . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 3.
Je n'ai peut-être pas capté un truc, mais pourquoi ne fait-il pas le SIGSTOP après ? Le coup de ne pouvoir surveiller que son fils, c'est sans utiliser les cgroup, hors, systemd l'utilise justement. Et même, pourquoi n'exec-t-il pas erl ? Bon, il a peut-être des raisons, et le coup du SIGSTOP peut effectivement sembler bidouille dans ce cas.
OK, merci de l'explication sur les désavantages, je comprends mieux. À la base, je disais juste que l'excuse de « le coup du SIGSTOP est pourri car upstart le fait mal » me semblait en légère. Je suis d'accord du coup que ça n'est pas forcément le mieux.
Rho, c'était pas une attaque ad hominem, c'était juste pour dire que ta remarque « c'est super facile de rajouter une dépendance » ne sera peut-être pas acceptée par tous les développeurs : oui, quand tu connais, c'est plus ou moins facile, mais en général les devs upstream ont besoin de faire appel à des empaqueteurs aguerris pour les aider à gérer tout ce bordel. Ça n'est pas pour rien que tout le monde peste contre les autotools : ils ne sont pas facile à aborder. (je ne dis pas qu'ils sont mauvais, au contraire : je suis même en train d'écrire une doc sur mon expérience dessus)
Quant à ton nick, oui, je sais que tu n'es pas un débutant, je fréquente linuxfr depuis un bout de temps quand même... ne le prend pas personnellement.
J'espère que ça peut être aussi facile que tu le dis. Vu l'inter-dépendance de tous les morceaux de systemd, je me permets d'avoir un petit doute, mais comme je n'ai pas regardé, je ne protesterais pas plus que ça.
Ah ? Merde, j'aurais dû vérifier, je pensais que c'était plus courant /o\
Note que ces points deux et trois sont aussi valables avec systemd.
Oui, mais dans ce que tu cites, c'est souvent soit pour enlever des trucs, soit pour adapter du code existant. L'ajout de dépendance sur un autre logiciel, pas prévu au début pour le programme, ça rentre pour moi quand même dans une catégorie un peu plus pointue de travail et potentiellement d'emmerdes. Mais bon, si ça permet d'améliorer la gestion de démons du système, ça mettra peut-être plus de motivation dans le cœur des empaqueteurs...
Perso, je trouverais ça pratique avec des softs qui ont des comportements pas facile à gérer pour moi ; typiquement, qui offrent un socket de contrôle, mais qui est créé après que l'exécutable se soit démonisé. Typiquement, dans le monde réel, ça passe, mais en VM ça va tellement vite que mes scripts d'init doivent kludger (sleep...) pour que ça marche. C'est pour ça que si systemd prend bien, et que le travail colossal pour l'intégrer est fait, je trouverai ça bien au final.