En fait, en cherchant un peu, j'ai trouvé d'autres soucis.
4) ton script s'appuie sur le pid, donc si on perds le fichier, on perds une partie de l'etat. Pire encore, si on reboote la machine brutalement ( coupure de courant ), le fichier pid reste la, et bloque le démarrage de stunnel. Ou, si stunnel écrase le fichier existant, alors on peut imaginer l'inverse, on lance 2 fois le script ( cf point 6 ), et le 2eme fait qu'on perds le pid du premier, sauf si stunnel n'écrit pas le pid car le premier est lancé.
Et je parle pas d'avoir /var/lib en readonly ( livecd, etc ). Mais bon, c'est un détail, on peut supposer trivialement que ça se trouve dans /var/run, un truc poussé par systemd au passage.
C'est un tmpfs donc ça régle le souci.
5) il n'y a aucun nettoyage de l’environnement. Si ma locale est en français, alors stunnel sera en français, avec ce que ça implique ( message de log, format des dates, etc ). Parfois, ça change rien. Et parfois, ça change. Et comme c'est un script, tu peux toujours avoir quelqu'un qui le lance en dehors de service ou équivalent. Un souci que systemd n'a pas en forçant le passage par systemctl.
6) ton script ne renvoie pas de code de retour différents pour status. Donc un outil comme puppet va pas réussir à voir si le logiciel est lancé ou pas. Et les codes de retour sont spécifiés dans la LSB. Encore une fois, systemd unifie ça et évite de refaire le code à chaque fois.
7) Il se passe quoi si stunnel mets plus d'une seconde à s’arrêter, et que tu fais un restart ( genre ta machine est bien surchargé avec plein de load ). Réponse, il se relance pas, parce que le stop ne garanti pas que le process est coupé. C'est aussi un souci que systemd gère correctement ( en étant sur que les processus sont morts, dans le cgroup ).
Tout ça, ça se corrige dans ton script. Mais c'est surtout pour montrer que c'est pas aussi simple que ça de faire un truc robuste ( car bon, en dehors des commentaires de Linuxfr, les machines ont des coupures de courants, les machines ont du load, les gens utilisent puppet/ansible, les processus se plantent, les gens font des erreurs de config ).
[^] # 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.
En fait, en cherchant un peu, j'ai trouvé d'autres soucis.
4) ton script s'appuie sur le pid, donc si on perds le fichier, on perds une partie de l'etat. Pire encore, si on reboote la machine brutalement ( coupure de courant ), le fichier pid reste la, et bloque le démarrage de stunnel. Ou, si stunnel écrase le fichier existant, alors on peut imaginer l'inverse, on lance 2 fois le script ( cf point 6 ), et le 2eme fait qu'on perds le pid du premier, sauf si stunnel n'écrit pas le pid car le premier est lancé.
Et je parle pas d'avoir /var/lib en readonly ( livecd, etc ). Mais bon, c'est un détail, on peut supposer trivialement que ça se trouve dans /var/run, un truc poussé par systemd au passage.
C'est un tmpfs donc ça régle le souci.
5) il n'y a aucun nettoyage de l’environnement. Si ma locale est en français, alors stunnel sera en français, avec ce que ça implique ( message de log, format des dates, etc ). Parfois, ça change rien. Et parfois, ça change. Et comme c'est un script, tu peux toujours avoir quelqu'un qui le lance en dehors de service ou équivalent. Un souci que systemd n'a pas en forçant le passage par systemctl.
6) ton script ne renvoie pas de code de retour différents pour status. Donc un outil comme puppet va pas réussir à voir si le logiciel est lancé ou pas. Et les codes de retour sont spécifiés dans la LSB. Encore une fois, systemd unifie ça et évite de refaire le code à chaque fois.
7) Il se passe quoi si stunnel mets plus d'une seconde à s’arrêter, et que tu fais un restart ( genre ta machine est bien surchargé avec plein de load ). Réponse, il se relance pas, parce que le stop ne garanti pas que le process est coupé. C'est aussi un souci que systemd gère correctement ( en étant sur que les processus sont morts, dans le cgroup ).
Tout ça, ça se corrige dans ton script. Mais c'est surtout pour montrer que c'est pas aussi simple que ça de faire un truc robuste ( car bon, en dehors des commentaires de Linuxfr, les machines ont des coupures de courants, les machines ont du load, les gens utilisent puppet/ansible, les processus se plantent, les gens font des erreurs de config ).