Pour ma part, j'ai utilisé runit en production, pas juste sur une VM par curiosité. C'est un bon outil, mais j'ai basculé sans hésitation vers systemd quand Jessie est sortie.
D'abord, il faut rappeler que runit ne suit pas la norme SysVinit. Donc il faut se coltiner l'écriture de scripts en shell pour piloter le démarrage des services, en remplacement de ceux écrits dans /etc/init.d/. Debian ne les fournit pas et qu'il n'y a pas une grosse communauté autour de runit (admirez la litote ;-).
Mon besoin était de surveiller (monitoring) des services dont l'un n'avait pas de mode démon. Il n'écrivait même pas son PID dans un fichier. Ça a l'air tout bête, mais il n'y a guère d'outil pour surveiller un service de ce type, et le relancer en cas de crash ou de signal d'arrêt. C'est pour ça que j'avais opté pour runit.
Par contre, je me suis retrouvé avec le problème inverse : il fallait que les services soit lancés en premier plan, sans forker en tâche de fond. Et Runit n'utilise pas les cgroups, donc un service peut échapper à son gestionnaire — à sa décharge, les cgroups sont apparus bien après lui.
En pratique, je trouvais aussi que runit n'étais pas si simple que ça à administrer. Par exemple, je lançais autant que possible les processus avec des utilisateurs différents, pour des raisons de sécurité. Avec Runit, soit il faut activer un mécanisme global de déclaration dans les répertoires des utilisateurs, soit il faut jouer avec su dans les scripts shell des services. Autre exemple, la gestion des dépendances est vraiment très sommaire : c'est au script shell de tester si ses pré-requis sont là, et de quitter s'il manque quelque chose, ensuite runit essaie de le relancer plus tard.
Quant à la vitesse, oui runit est rapide, mais je doute qu'il le soit plus que systemd, notamment parce qu'il lance un nouveau shell pour chaque service. De toutes façons, quand une machine démarre en moins de 5 secondes, je ne vais pas faire la course pour quelques dixièmes.
J'ai du respect pour runit, un petit outil bien fait (hélas peu documenté), mais à mon avis il n'a pas la carrure pour être le gestionnaire de démarrage d'une grande distribution.
[^] # Runit
Posté par rogo . En réponse à la dépêche Debian Jessie, 1 an plus tard. Évalué à 10. Dernière modification le 10 juin 2016 à 10:57.
Pour ma part, j'ai utilisé runit en production, pas juste sur une VM par curiosité. C'est un bon outil, mais j'ai basculé sans hésitation vers systemd quand Jessie est sortie.
D'abord, il faut rappeler que runit ne suit pas la norme SysVinit. Donc il faut se coltiner l'écriture de scripts en shell pour piloter le démarrage des services, en remplacement de ceux écrits dans /etc/init.d/. Debian ne les fournit pas et qu'il n'y a pas une grosse communauté autour de runit (admirez la litote ;-).
Mon besoin était de surveiller (monitoring) des services dont l'un n'avait pas de mode démon. Il n'écrivait même pas son PID dans un fichier. Ça a l'air tout bête, mais il n'y a guère d'outil pour surveiller un service de ce type, et le relancer en cas de crash ou de signal d'arrêt. C'est pour ça que j'avais opté pour runit.
Par contre, je me suis retrouvé avec le problème inverse : il fallait que les services soit lancés en premier plan, sans forker en tâche de fond. Et Runit n'utilise pas les cgroups, donc un service peut échapper à son gestionnaire — à sa décharge, les cgroups sont apparus bien après lui.
En pratique, je trouvais aussi que runit n'étais pas si simple que ça à administrer. Par exemple, je lançais autant que possible les processus avec des utilisateurs différents, pour des raisons de sécurité. Avec Runit, soit il faut activer un mécanisme global de déclaration dans les répertoires des utilisateurs, soit il faut jouer avec
sudans les scripts shell des services. Autre exemple, la gestion des dépendances est vraiment très sommaire : c'est au script shell de tester si ses pré-requis sont là, et de quitter s'il manque quelque chose, ensuite runit essaie de le relancer plus tard.Quant à la vitesse, oui runit est rapide, mais je doute qu'il le soit plus que systemd, notamment parce qu'il lance un nouveau shell pour chaque service. De toutes façons, quand une machine démarre en moins de 5 secondes, je ne vais pas faire la course pour quelques dixièmes.
J'ai du respect pour runit, un petit outil bien fait (hélas peu documenté), mais à mon avis il n'a pas la carrure pour être le gestionnaire de démarrage d'une grande distribution.