Tu peux avoir un service qui fait ça. Il vérifie le processus comme tu le souhaite, puis si vraiment il y a un problème il le dézingue et systemd le relancera.
Déjà j'aime pas trop "dézinguer" un service qui tourne, même si avec systemd il y a un relatif ménage derrière qui évite les zombis et les processus fils qui trainent (Mais qui n'évite pas forcément la rémanence de données inutiles dans les applis connectées à ce service, le post-traitement n'est pas appelé etc.)
Autre effet désagréable si on relance le service de cette façon, systemd va compter un "fail". Donc pour que le service soit relancé à chaque fois, il faut configurer systemd pour qu'il relance le service systématiquement. Ce qui n'est pas sans effet de bord quand le service se met vraiment à merder tout seul comme un grand.
Ensuite, c'est bien beau pour un service, mais pour deux cents ca devient pénible. Si on décide de faire des procédures différentes par client, de modifier toute sles procédures de surveillance, de changer temporairement une procédure (par exemple le client prévient qu'il y aura une forte charge et/ou des tests pendant une semaine) etc. Ben tu as deux cents services à mettre à jour. Quand c'est fait depuis Nagios, tu as une règle à changer - tu es sur de ne pas oublier de règle puisque tout est centralisé etc.
Finalement à ce compte là autant avoir un script à l'ancienne qui essaye au moins d'arréter le service proprement, tout en faisant la nique à systemd. Mais ca n'est pas possible avec tous les services (des que l'on touche au réseau en dehors de networkd, il se passe des choses indésirables). Pendant qu'on y est on va même carrément mettre ce script comme cible de l'unit systemd - comme ça systemd lance un script qui à son tour lance le programme voulu. Un émulateur sysV en quelque sorte - mais avec une interface de plus.
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 1.
Tu peux avoir un service qui fait ça. Il vérifie le processus comme tu le souhaite, puis si vraiment il y a un problème il le dézingue et systemd le relancera.
Déjà j'aime pas trop "dézinguer" un service qui tourne, même si avec systemd il y a un relatif ménage derrière qui évite les zombis et les processus fils qui trainent (Mais qui n'évite pas forcément la rémanence de données inutiles dans les applis connectées à ce service, le post-traitement n'est pas appelé etc.)
Autre effet désagréable si on relance le service de cette façon, systemd va compter un "fail". Donc pour que le service soit relancé à chaque fois, il faut configurer systemd pour qu'il relance le service systématiquement. Ce qui n'est pas sans effet de bord quand le service se met vraiment à merder tout seul comme un grand.
Ensuite, c'est bien beau pour un service, mais pour deux cents ca devient pénible. Si on décide de faire des procédures différentes par client, de modifier toute sles procédures de surveillance, de changer temporairement une procédure (par exemple le client prévient qu'il y aura une forte charge et/ou des tests pendant une semaine) etc. Ben tu as deux cents services à mettre à jour. Quand c'est fait depuis Nagios, tu as une règle à changer - tu es sur de ne pas oublier de règle puisque tout est centralisé etc.
Finalement à ce compte là autant avoir un script à l'ancienne qui essaye au moins d'arréter le service proprement, tout en faisant la nique à systemd. Mais ca n'est pas possible avec tous les services (des que l'on touche au réseau en dehors de networkd, il se passe des choses indésirables). Pendant qu'on y est on va même carrément mettre ce script comme cible de l'unit systemd - comme ça systemd lance un script qui à son tour lance le programme voulu. Un émulateur sysV en quelque sorte - mais avec une interface de plus.