je vois un certain nombre de souci avec ton script.
1) il se passe quoi si la config de stunnel fait que le pid est ailleurs ? Faut changer le script. mais du coup, comme le script est sous le controle du gestionnaire de paquet, y a un conflit si le packageur mets à jour le script.
2) tu part du principe que le PID dans $PIDFILE est celui de stunnel. C'est une supposition dangereuse à faire. Par exemple, stunnel crash ( un bon segfault des familles ), le pid est repris par un autre process. Tu fait un status, il va te dire que stunnel tourne, alors que non. Du coup, tu fait un stop. Et le process qui a repris le PID se fait tuer.
3) il se passe quoi si quelqu'un configure stunnel par erreur pour ne pas passer en background ? Le script bloque. En fonction du systéme d'init, ça peut bloquer le boot.
Alors bien sur, systemd va pas forcément résoudre le point 1. mais systemd va te dire "le fichier PID n'est pas la, j'ai un souci" si tu utilises PIDFile et que rien n'apparait. Systemd va pas avoir le souci du 2. Et pour le 3, c'est pareil, systemd va voir qu'il y a un souci, et comme il fforke avant de lancer, il va pas bloquer quoi que ce soit.
[^] # Re: If it works, don't fix it.
Posté par Misc (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 8.
je vois un certain nombre de souci avec ton script.
1) il se passe quoi si la config de stunnel fait que le pid est ailleurs ? Faut changer le script. mais du coup, comme le script est sous le controle du gestionnaire de paquet, y a un conflit si le packageur mets à jour le script.
2) tu part du principe que le PID dans $PIDFILE est celui de stunnel. C'est une supposition dangereuse à faire. Par exemple, stunnel crash ( un bon segfault des familles ), le pid est repris par un autre process. Tu fait un status, il va te dire que stunnel tourne, alors que non. Du coup, tu fait un stop. Et le process qui a repris le PID se fait tuer.
3) il se passe quoi si quelqu'un configure stunnel par erreur pour ne pas passer en background ? Le script bloque. En fonction du systéme d'init, ça peut bloquer le boot.
Alors bien sur, systemd va pas forcément résoudre le point 1. mais systemd va te dire "le fichier PID n'est pas la, j'ai un souci" si tu utilises PIDFile et que rien n'apparait. Systemd va pas avoir le souci du 2. Et pour le 3, c'est pareil, systemd va voir qu'il y a un souci, et comme il fforke avant de lancer, il va pas bloquer quoi que ce soit.