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/.
Hum... sysVinit, il ne fait que lancer des services, il ne les gère pas. Il le faut au travers de scripts shell. Alors tout ce qui gère les services, sors forcément de la «norme» sysVinit.
Runit, il lance des services, et il les gère. Au travers de scripts shell.
Le langage shell utilisé est le même pour les deux cas. Du coup, je ne vois pas trop comment runit ferait moins bien que sysVinit?
Je reconnais n'avoir pas essayé, mais, ça ne marche pas de lancer les scripts de /etc/init.d par runit?
Et le coup de la norme sysVinit pas respectée, ça ne prend pas.
Oui, systemd peut lancer des scripts sysVinit (comme runit, j'en suis persuadé), mais il ne respecte pas non plus celle-ci. Donc il faut se «coltiner» (ton terme) l'écriture de fichiers de config avec la syntaxe de systemd .
Maintenant, je trouve que le shell à une syntaxe de merde (et des mots-clé à la con, genre fi et esac, par contre pas de rof ni de elihw? Mots clé à la con, et même pas consistants! Je ne parlerai pas de test, à chaque fois que je m'en sers, je sors le man!), est bourré de chausses-trappes et à pleins d'autres inconvénients (me semble plusieurs de ces inconvénients on causé la naissance de perl, d'ailleurs).
Mais pas obligé de connaître le shell pour écrire des scripts runit, rien n'empêche d'utiliser python par exemple (j'en ai vu un exemple sur github, il y a quelques jours).
D'un autre côté, systemd «impose» un langage, plus simple qu'un langage de programmation. Par contre, il s'agit d'une technologie spécifique, qui ne servira que pour systemd.
Du coup, vraiment, l'argument de la norme en faveur de systemd et contre runit il est pas terrible :)
D'ailleurs, le coup d'utiliser un autre langage pour écrire les scripts d'init, pourquoi ne pas l'avoir utilisé pour sysVinit? Je viens de réaliser que je n'ai pas souvenir d'avoir lu quoique ce soit à ce sujet? Ça aurait sûrement pu simplifier énormément les usines à gaz.
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.
Oui, c'est le problème, le service doit avoir un moyen de ne pas utiliser le double fork. Qui ressemble quand même pas mal à un workaround, pour moi (traditionnel, certes, mais workaround quand même).
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.
Ou utiliser le programme chpst fourni par runit? Cet outil est vraiment très intéressant, il permets notamment de:
changer l'utilisateur
les groupes du processus
les variables d'environnement (bien apprécié ça, récemment) en définissant un dossier dont chaque fichier/contenu est une variable/valeur
créer un fichier de verrouillage. Peut-être que ça aurait pu résoudre ton problème de fichier PID manquant? (je viens de l'apprendre, cette option, j'ai ouvert le man par curiosité)
Par contre, je ne sais pas s'il y a un workaround contre les programmes qui exigent de forker. À part les forker eux, pour faire sauter le double fork et recompiler, bien sûr :D
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.
C'est vrai, le lancement d'un shell est lent. Celui qui lance des bash à chaque fois dois prendre bien cher... d'un autre côté, celui qui lance juste busybox-static, ça doit être raisonnable, niveau coût.
Par contre, je ne sais pas du tout comment systemd marche, de ce côté la. C'est un binaire séparé de l'init qui lit la config?
(hélas peu documenté)
C'est vrai, la documentation tiens sur peu de place. D'un autre côté, je n'ai pas l'impression qu'il y ait besoin de plus. Après tout, runit délègue au système la plupart de ses actions. Alors que systemd c'est plutôt le contraire, il prend les prérogatives du système pour la plupart des actions du systèmes :)
il n'y a pas une grosse communauté autour de runit (admirez la litote ;-).
Oui, je pense que c'est une des raisons qui fait qu'il n'est pas utilisé plus que ça.
à mon avis il n'a pas la carrure pour être le gestionnaire de démarrage d'une grande distribution.
Probablement. Le point le plus noir étant probablement sa communauté trop réduite. Du coup, effectivement, peu de scripts sont fournis, et soyons honnêtes, ceux du site officiel semblent un peu obsolètes.
Je ne pense pas que runit vise à gérer le démarrage d'une grande distribution. Pour moi, il est plus adapté à des distributions qui cherchent à laisser le contrôle à l'utilisateur. Ne serait-ce que par la quasi absence de comportement par défaut.
[^] # Re: Runit
Posté par freem . En réponse à la dépêche Debian Jessie, 1 an plus tard. Évalué à 3.
Hum... sysVinit, il ne fait que lancer des services, il ne les gère pas. Il le faut au travers de scripts shell. Alors tout ce qui gère les services, sors forcément de la «norme» sysVinit.
Runit, il lance des services, et il les gère. Au travers de scripts shell.
Le langage shell utilisé est le même pour les deux cas. Du coup, je ne vois pas trop comment runit ferait moins bien que sysVinit?
Je reconnais n'avoir pas essayé, mais, ça ne marche pas de lancer les scripts de /etc/init.d par runit?
Et le coup de la norme sysVinit pas respectée, ça ne prend pas.
Oui, systemd peut lancer des scripts sysVinit (comme runit, j'en suis persuadé), mais il ne respecte pas non plus celle-ci. Donc il faut se «coltiner» (ton terme) l'écriture de fichiers de config avec la syntaxe de systemd .
Maintenant, je trouve que le shell à une syntaxe de merde (et des mots-clé à la con, genre fi et esac, par contre pas de rof ni de elihw? Mots clé à la con, et même pas consistants! Je ne parlerai pas de
test, à chaque fois que je m'en sers, je sors le man!), est bourré de chausses-trappes et à pleins d'autres inconvénients (me semble plusieurs de ces inconvénients on causé la naissance de perl, d'ailleurs).Mais pas obligé de connaître le shell pour écrire des scripts runit, rien n'empêche d'utiliser python par exemple (j'en ai vu un exemple sur github, il y a quelques jours).
D'un autre côté, systemd «impose» un langage, plus simple qu'un langage de programmation. Par contre, il s'agit d'une technologie spécifique, qui ne servira que pour systemd.
Du coup, vraiment, l'argument de la norme en faveur de systemd et contre runit il est pas terrible :)
D'ailleurs, le coup d'utiliser un autre langage pour écrire les scripts d'init, pourquoi ne pas l'avoir utilisé pour sysVinit? Je viens de réaliser que je n'ai pas souvenir d'avoir lu quoique ce soit à ce sujet? Ça aurait sûrement pu simplifier énormément les usines à gaz.
Oui, c'est le problème, le service doit avoir un moyen de ne pas utiliser le double fork. Qui ressemble quand même pas mal à un workaround, pour moi (traditionnel, certes, mais workaround quand même).
Ou utiliser le programme chpst fourni par runit? Cet outil est vraiment très intéressant, il permets notamment de:
Par contre, je ne sais pas s'il y a un workaround contre les programmes qui exigent de forker. À part les forker eux, pour faire sauter le double fork et recompiler, bien sûr :D
C'est vrai, le lancement d'un shell est lent. Celui qui lance des bash à chaque fois dois prendre bien cher... d'un autre côté, celui qui lance juste busybox-static, ça doit être raisonnable, niveau coût.
Par contre, je ne sais pas du tout comment systemd marche, de ce côté la. C'est un binaire séparé de l'init qui lit la config?
C'est vrai, la documentation tiens sur peu de place. D'un autre côté, je n'ai pas l'impression qu'il y ait besoin de plus. Après tout, runit délègue au système la plupart de ses actions. Alors que systemd c'est plutôt le contraire, il prend les prérogatives du système pour la plupart des actions du systèmes :)
Oui, je pense que c'est une des raisons qui fait qu'il n'est pas utilisé plus que ça.
Probablement. Le point le plus noir étant probablement sa communauté trop réduite. Du coup, effectivement, peu de scripts sont fournis, et soyons honnêtes, ceux du site officiel semblent un peu obsolètes.
Je ne pense pas que runit vise à gérer le démarrage d'une grande distribution. Pour moi, il est plus adapté à des distributions qui cherchent à laisser le contrôle à l'utilisateur. Ne serait-ce que par la quasi absence de comportement par défaut.