Non, justement c'est tout le contraire : dans sysvinit les démons doivent se détacher pour que le script puisse retourner après que tu appelles start.
En gros, dans sysvinit, les scripts servent juste à lancer et arrêter les démons, en espérant qu'ils continuent à s'exécuter correctement dans l'intervalle (en se détachant par double fork). Et dans runit, à l'inverse, les démons restent attaché au processus runsv qui les a lancé, et qui peut donc détecter quand ils meurent et les relancer immédiatement (enfin avec un délai d'une seconde pour éviter de surcharger ton CPU si un démon se plante à répétition). C'est évidemment l'approche de runit qui est la bonne : essayer de maintenir de l'état sans surveiller comme sysvinit, c'est voué à l'échec.
[^] # Re: systemd
Posté par MrLapinot (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 2.
Non, justement c'est tout le contraire : dans sysvinit les démons doivent se détacher pour que le script puisse retourner après que tu appelles start.
En gros, dans sysvinit, les scripts servent juste à lancer et arrêter les démons, en espérant qu'ils continuent à s'exécuter correctement dans l'intervalle (en se détachant par double fork). Et dans runit, à l'inverse, les démons restent attaché au processus runsv qui les a lancé, et qui peut donc détecter quand ils meurent et les relancer immédiatement (enfin avec un délai d'une seconde pour éviter de surcharger ton CPU si un démon se plante à répétition). C'est évidemment l'approche de runit qui est la bonne : essayer de maintenir de l'état sans surveiller comme sysvinit, c'est voué à l'échec.