En fait, la méthode à base de echo, elle est furieusement semblable à ce que tu doit sans doute faire en écrivant dans un fichier la liste des PIDs. ( et sincèrement, ne dit pas "j'ai pas le temps d'apprendre". Si on a le temps de poster sur linuxfr, on a le temps de lire la doc )
Pour ton histoire de maintenance, la solution est pourtant simple, tu peux faire un second service avec juste la config qui diffère. En te démerdant bien, systemctl isolate doit même pouvoir faire des trucs plus chiadés qui devrait te permettre de faire encore plus complexe. Ou attends, même mieux, tu changes la config, et tu recharge le service. Ou mieux, tu fait comme avec sysvinit, tu stoppes le service et tu lances à la main, puis tu fais l'inverse.
Mais sans doute qu'il y a une raison non exprimé qui fait que faire la même chose, ça va pas marcher ?
Si tu veux lancer un tunnel gre non ip, ben tu fait un unité qui le fait, et tu t'arrange pour que ça soit fait avant network ( en rajoutant, genre "before" dans l'unité ). Ou tu le fait via modprobe.conf, pour lancer le script avant de charger le module pour ip ( tout comme certaines distros font pour alsa, pour charger le volume, ou pour les firmwares ). Actuellement, tu as sans doute du écrire ton propre script, et visiblement, ton cas d'usage est assez rare pour que personne ne propose de patch ( à commencer par toi, en fait ), et pourtant, tu es pas bloqué le moins du monde. En fait, tu peux aussi juste rajoute rune unité network qui remplace celle de systemd, et grâce à l'usage judicieux de répertoire, ça va pas casser à l'upgrade d'un rpm. Marvelous, non ?
Enfin pour l'exemple d'apache avec préservation des sockets ( je suppose que tu veux dire dans ce cas précis port tcp ), la réponse est "la même chose que si tu as lancé apache via xinetd", vu que ( http://0pointer.de/blog/projects/inetd.html ) c'est le même système. En d'autres termes, tout comme lancer apache via xinetd va pas marcher si tu lance apache à coté une 2eme fois ( vu que le port tcp va être ouvert par xinetd ou systemd ), ça va pas marcher des masses de faire ça via systemd.
Mais comme la config par défaut pour apache, c'est justement de faire lancer apachectl ( ou plutot httpd -k ), le souci ne se poseras pas par défaut. Et en fait, si tu configures ça pour marcher en mode socket et que tu utilises le script qui est prévu pour marcher avec l'autre mode ( ie standalone ), c'est plus toi qui fait exprès un truc qui ne va pas marcher par design du mode xinetd d'apache ( ie le souci n'est pas lié à systemd, vu qu'il se pose aussi . Comme se dire "bah j'utilise nginx, pourquoi apachectl marche pas". Réponse, parce que tu as 2 modes différents pas prévus pour être mélangés dans apache, et c'est à apache de gérer le cas comme il faut.
En pratique, le mode inetd n'est plus dans apache 2 ( plus de directive ServerType cf http://httpd.apache.org/docs/2.0/en/upgrading.html ), et donc, ton exemple reste un exemple purement théorique. Mais tu peux continuer à dire que systemd fait mal les choses car les programmes peuvent proposer 2 modes incompatibles de lancement.
Sinon, je voit pas de boilerplate ajouté dans systemd dans tes exemples, je vois juste du boilerplate que tu as ajouté dans ton système, ce qui pour moi est différent ( ie, tu es responsable des kludges que tu fait, le reste du monde s'arrange pour faire des trucs propres ).
[^] # Re: Questions
Posté par Misc (site web personnel) . En réponse au journal Linux from scratch face à udev. Évalué à 5.
Pour bouger des pid dans le cgroup, c'est écrit dans la doc qui se trouve facilement via "cgroup pid move" sur un moteur de recherche. Exemple de résultat :
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/sec-Moving_a_Process_to_a_Control_Group.html
En fait, la méthode à base de echo, elle est furieusement semblable à ce que tu doit sans doute faire en écrivant dans un fichier la liste des PIDs. ( et sincèrement, ne dit pas "j'ai pas le temps d'apprendre". Si on a le temps de poster sur linuxfr, on a le temps de lire la doc )
Pour tes trucs trop compliqués ou spécifiques, je pense qu'il a été dit facile 20 fois "tu peux garder ton script sysv". Voir même, tu peux lancer un script shell via systemd. Exemple de truc qui serait sans doute digne de la complexité dans laquelle tu aimes baigner :
http://kezhong.wordpress.com/2011/11/19/creating-my-own-systemd-service-files-on-fedora-16x86_64/
pareil, moteur de recherche, temps, linuxfr, etc
Pour ton histoire de maintenance, la solution est pourtant simple, tu peux faire un second service avec juste la config qui diffère. En te démerdant bien, systemctl isolate doit même pouvoir faire des trucs plus chiadés qui devrait te permettre de faire encore plus complexe. Ou attends, même mieux, tu changes la config, et tu recharge le service. Ou mieux, tu fait comme avec sysvinit, tu stoppes le service et tu lances à la main, puis tu fais l'inverse.
Mais sans doute qu'il y a une raison non exprimé qui fait que faire la même chose, ça va pas marcher ?
Si tu veux lancer un tunnel gre non ip, ben tu fait un unité qui le fait, et tu t'arrange pour que ça soit fait avant network ( en rajoutant, genre "before" dans l'unité ). Ou tu le fait via modprobe.conf, pour lancer le script avant de charger le module pour ip ( tout comme certaines distros font pour alsa, pour charger le volume, ou pour les firmwares ). Actuellement, tu as sans doute du écrire ton propre script, et visiblement, ton cas d'usage est assez rare pour que personne ne propose de patch ( à commencer par toi, en fait ), et pourtant, tu es pas bloqué le moins du monde. En fait, tu peux aussi juste rajoute rune unité network qui remplace celle de systemd, et grâce à l'usage judicieux de répertoire, ça va pas casser à l'upgrade d'un rpm. Marvelous, non ?
Enfin pour l'exemple d'apache avec préservation des sockets ( je suppose que tu veux dire dans ce cas précis port tcp ), la réponse est "la même chose que si tu as lancé apache via xinetd", vu que ( http://0pointer.de/blog/projects/inetd.html ) c'est le même système. En d'autres termes, tout comme lancer apache via xinetd va pas marcher si tu lance apache à coté une 2eme fois ( vu que le port tcp va être ouvert par xinetd ou systemd ), ça va pas marcher des masses de faire ça via systemd.
Mais comme la config par défaut pour apache, c'est justement de faire lancer apachectl ( ou plutot httpd -k ), le souci ne se poseras pas par défaut. Et en fait, si tu configures ça pour marcher en mode socket et que tu utilises le script qui est prévu pour marcher avec l'autre mode ( ie standalone ), c'est plus toi qui fait exprès un truc qui ne va pas marcher par design du mode xinetd d'apache ( ie le souci n'est pas lié à systemd, vu qu'il se pose aussi . Comme se dire "bah j'utilise nginx, pourquoi apachectl marche pas". Réponse, parce que tu as 2 modes différents pas prévus pour être mélangés dans apache, et c'est à apache de gérer le cas comme il faut.
En pratique, le mode inetd n'est plus dans apache 2 ( plus de directive ServerType cf http://httpd.apache.org/docs/2.0/en/upgrading.html ), et donc, ton exemple reste un exemple purement théorique. Mais tu peux continuer à dire que systemd fait mal les choses car les programmes peuvent proposer 2 modes incompatibles de lancement.
Sinon, je voit pas de boilerplate ajouté dans systemd dans tes exemples, je vois juste du boilerplate que tu as ajouté dans ton système, ce qui pour moi est différent ( ie, tu es responsable des kludges que tu fait, le reste du monde s'arrange pour faire des trucs propres ).