T'es pas obligé de lancer un signal KILL, non plus.
Peut importe le signal que je lance, il faut que ce soit interprété comme un fail par systemd. (Si je mets le service en restart même sur un status de sortie correct, ca veut dire que je ne peux plus jamais arréter le service à moins d'éteindre la machine.)
A partir de là, a part sigkill, sigterm et sigint j'ai pas grand chose.
Si le process est solitaire, un sigterm peut permettre une sortie en douceur si tout va bien, mais si il y a plusieurs processus ou que sigterm ne suffit pas il faut y aller plus fort. Et là le fait que mon service secondaire ne soit pas l'init que les différentes infos ne soient plus logguées comme avant et qu'elle ne soit pas accessible facilement par un processus non root peut entrainer des problèmes.
Tu as plusieurs politiques dans systemd en jouant avec Restart et SuccessExitStatus tu devrais pourvoir faire en sorte que systemd relance le service quand quand tu le souhaite.
Pas vraiment non. Si c'est le service "moniteur" qui envoie un sigkill, je veux que le service monitoré redémarre. Par contre si c'est moi qui envoit le sigkill je veux que ce soit pris en compte comme un ordre définitif. Généralement je ne fais pas de sigkill, mais quand j'en fais un c'est pas pour que le processus soit relancé immédiatement.
Et l'action de Nagios ça ne peut pas être de simplement tuer les processus à relancer ?
Pour certains services problématiques, c'est déjà le cas aujourd'hui, mais après avoir tenté plusieurs fois une extinction propre via les commandes init.
J'ai l'impression que ce qui te pose problème ça n'est pas l'architecture de systemd, c'est juste que son API dBus ne serait accessible qu'à root (ce qui me surprends).
D'un autre coté, le fait que le bus systeme avec la target qui controle tous les services ne soit acessible que à root n'est pas franchement choquant.
Ce qui est plus embétant c'est que systemd ne possède aucun moyen de lui passer des paramètres dynamiquement que ce soit à l'init ou pendant la vie du service.(j'ai bien dit "des" je sais qu'on peu en passer un via @ à l'init.)
Je ne serai pas aussi négatif si il y avait les fonctions suivantes dans systemd
- Un moyen de lancer plusieurs fois la même unit avec des paramètres différents (ex : /etc/init.d/startvirtualnet --ip=192.168.200.0/24 --with-dhcp=192.168.200.1 --vinterface=vl12)
- un moyen de balancer des messages au service en cours d'éxecution (ex: /etc/init.d/service --rehash --reindex)
- un moyen d'autoriser des services non root à lancer les deux types de commandes ci dessus.
A l'heure actuelle pour chaque service lancé par systemd je suis obligé de chopper le PID au vol et de le stoquer pour pouvoir balancer les commandes directement, d'enregistrer et de détruire des units à tour de bras et le tout en faisant gaffe à ce que systemd ne prenne pas mal ce que je suis en train de faire.
Le reste ça me semble plutôt intéressant de faire gérer les services via un seul point (systemd) qui va gérer ça aussi proprement et de manière aussi centralisée que possible.
La question est limite philosophique, mais je ne considère pas que gérer un service se limite à le lancer, le logguer et à l'arréter. Pas mal de service son des options que l'on peut régler dynamiquement, tant que l'on ne peut pas les gérer depuis systemd, on se trouve à écrire des gestionnaires secondaires pour faire tout ce que systemd ne gère pas.
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 3.
T'es pas obligé de lancer un signal KILL, non plus.
Peut importe le signal que je lance, il faut que ce soit interprété comme un fail par systemd. (Si je mets le service en restart même sur un status de sortie correct, ca veut dire que je ne peux plus jamais arréter le service à moins d'éteindre la machine.)
A partir de là, a part sigkill, sigterm et sigint j'ai pas grand chose.
Si le process est solitaire, un sigterm peut permettre une sortie en douceur si tout va bien, mais si il y a plusieurs processus ou que sigterm ne suffit pas il faut y aller plus fort. Et là le fait que mon service secondaire ne soit pas l'init que les différentes infos ne soient plus logguées comme avant et qu'elle ne soit pas accessible facilement par un processus non root peut entrainer des problèmes.
Tu as plusieurs politiques dans systemd en jouant avec Restart et SuccessExitStatus tu devrais pourvoir faire en sorte que systemd relance le service quand quand tu le souhaite.
Pas vraiment non. Si c'est le service "moniteur" qui envoie un sigkill, je veux que le service monitoré redémarre. Par contre si c'est moi qui envoit le sigkill je veux que ce soit pris en compte comme un ordre définitif. Généralement je ne fais pas de sigkill, mais quand j'en fais un c'est pas pour que le processus soit relancé immédiatement.
Et l'action de Nagios ça ne peut pas être de simplement tuer les processus à relancer ?
Pour certains services problématiques, c'est déjà le cas aujourd'hui, mais après avoir tenté plusieurs fois une extinction propre via les commandes init.
J'ai l'impression que ce qui te pose problème ça n'est pas l'architecture de systemd, c'est juste que son API dBus ne serait accessible qu'à root (ce qui me surprends).
D'un autre coté, le fait que le bus systeme avec la target qui controle tous les services ne soit acessible que à root n'est pas franchement choquant.
Ce qui est plus embétant c'est que systemd ne possède aucun moyen de lui passer des paramètres dynamiquement que ce soit à l'init ou pendant la vie du service.(j'ai bien dit "des" je sais qu'on peu en passer un via @ à l'init.)
Je ne serai pas aussi négatif si il y avait les fonctions suivantes dans systemd
- Un moyen de lancer plusieurs fois la même unit avec des paramètres différents (ex : /etc/init.d/startvirtualnet --ip=192.168.200.0/24 --with-dhcp=192.168.200.1 --vinterface=vl12)
- un moyen de balancer des messages au service en cours d'éxecution (ex: /etc/init.d/service --rehash --reindex)
- un moyen d'autoriser des services non root à lancer les deux types de commandes ci dessus.
A l'heure actuelle pour chaque service lancé par systemd je suis obligé de chopper le PID au vol et de le stoquer pour pouvoir balancer les commandes directement, d'enregistrer et de détruire des units à tour de bras et le tout en faisant gaffe à ce que systemd ne prenne pas mal ce que je suis en train de faire.
Le reste ça me semble plutôt intéressant de faire gérer les services via un seul point (systemd) qui va gérer ça aussi proprement et de manière aussi centralisée que possible.
La question est limite philosophique, mais je ne considère pas que gérer un service se limite à le lancer, le logguer et à l'arréter. Pas mal de service son des options que l'on peut régler dynamiquement, tant que l'on ne peut pas les gérer depuis systemd, on se trouve à écrire des gestionnaires secondaires pour faire tout ce que systemd ne gère pas.