Mettons que je sois fondé à vouloir utiliser un init codé dans la philosophie Unix. Bah j'ai dû aller chercher quelque chose d'autre que Debian
Je me demande comment tordre le cou à ce mythe... j'utilise Debian sous runit, ça juste marche, pas de soucis et, non, je n'ai pas compilé runit, j'ai juste sélectionné le paquet.
Je devrais le compiler, d'ailleurs, parce que le lien symbolique me coûte environ 1.5Mio de RSS par daemon géré, alors que si je compilais soit en statique soit en lien avec muslc au lieu de glibc, ça serait 8Kio (parce qu'en fait j'ai 2 process additionnels par daemon: le gestionnaire, et le logger).
Et ce, depuis avant qu'ils ne mettent systemd par défaut. Je veux bien qu'on tape sur Debian et systemd, mais ça serait pas mal de rester factuel au lieu de répandre des légendes: ça aiderait a garder le débat serein.
Il a toujours été possible d'installer, via le système de paquets et les paquets officiels, un init différent sous Debian (quant a ce que sysVinit+rc.d soient de la "philosophie Unix" je n'en ai pas tant que ça la certitude, après tout, cette philosophie indique que l'outil doit faire une seule tâche, la faire bien, et communiquer avec l'extérieur via stdin/stdout, entres autres?).
Après, malgré que je sois moi-même plutôt contre systemd, il faut reconnaître que c'est un outil qui a eu plusieurs mérites:
gestion des dépendances
watchdog
gestion des journaux
Tout ça, c'est lié, et sysVinit ne le fait pas. Rc.d non plus.
Le chien de garde (watchdog), est notamment une fonctionnalité utile quand on commence a vouloir des systèmes autonomes qui s'auto-réparent (dans les limites du faisable). Oui, ça veut dire qu'il est souhaitable qu'un service qui tombe redémarre tout seul (pour éviter de cramer du fioul sur 400Km juste pour faire un redémarrage, par exemple).
C'est faisable avec runit (et les daemontools de manière générale) mais ce n'est pas a franchement parler efficace, en pratique on laisse le travail de gérer les dépendances aux daemons eux-mêmes. Je le sais: je l'ai fait.
Ce simple fait indique que les daemons ne peuvent, de facto, pas faire "une seule chose et la faire bien", et ça encourage a hard-coder la dépendance à un truc tiers, donc a réduire le choix de l'admin pour ses outils.
De ce point de vue, systemd est plus UNIX que sysVinit+rc.d, qu'il a remplacés sur de nombreux systèmes.
Pour ce qui est de la gestion des journaux, il n'est pas impossible que si l'on ne s'était pas farci sysVinit+rc.d pendant des décennies, les daemons auraient adopté plus tôt un comportement plus générique, c'est à dire: émettre par défaut sur stdout ou stderr, en laissant au gestionnaire de services le soin de les rediriger et traiter ou il faut, au lieu de s'appuyer sur syslog, qui est un outil unique pour toutes les instances, fait qui implique que s'il tombe, est corrompu, ou autre, on perds potentiellement tous les logs.
On peut également citer le double-fork-trick.
Encore une fois, systemd (et ici daemontools et ses héritiers le font aussi bien) est largement plus UNIX que les outils qu'il a permis de remplacer.
Moi, bien que je n'aime pas du tout systemd, je lui suis reconnaissant: sans systemd et les problèmes autour, je n'aurai jamais su qu'il était possible aussi simplement de s'affranchir de sysVinit+rc.d, je n'aurai probablement jamais (ou alors bien plus tard) trouvé runit, mon init+gestionnaire de services actuel.
Systemd a beau être une usine à gaz, un monstre de complexité, un framework alors que je préfère les bibliothèques, avoir eu des failles de sécurité réseau... je le trouve malgré tout largement préférable à la situation dont il nous a sortis.
En fait, ironiquement, c'est grâce à systemd que certaines distro, dont debian, ont commencé à supporter plusieurs systèmes d'init pour de vrai (le support des init autres que sysVinit+rc.d dans Debian reste parcellaire, soit, mais avant c'était le vide inter-sidéral).
Et le pire dans tout ça, c'est que malgré mon discours ici plutôt en faveur de systemd, ben, je refuse toujours de l'utiliser, pour mes raisons propres (un init qui dépend de dbus est le genre de trucs qui me chatouillent un peu par exemple).
[^] # Re: mises à jour
Posté par freem . En réponse au journal 2 ans d'Artix Linux dans un GUL de province (GEBULL.org). Évalué à 9.
Je me demande comment tordre le cou à ce mythe... j'utilise Debian sous runit, ça juste marche, pas de soucis et, non, je n'ai pas compilé runit, j'ai juste sélectionné le paquet.
Je devrais le compiler, d'ailleurs, parce que le lien symbolique me coûte environ 1.5Mio de RSS par daemon géré, alors que si je compilais soit en statique soit en lien avec muslc au lieu de glibc, ça serait 8Kio (parce qu'en fait j'ai 2 process additionnels par daemon: le gestionnaire, et le logger).
Et ce, depuis avant qu'ils ne mettent systemd par défaut. Je veux bien qu'on tape sur Debian et systemd, mais ça serait pas mal de rester factuel au lieu de répandre des légendes: ça aiderait a garder le débat serein.
Il a toujours été possible d'installer, via le système de paquets et les paquets officiels, un init différent sous Debian (quant a ce que sysVinit+rc.d soient de la "philosophie Unix" je n'en ai pas tant que ça la certitude, après tout, cette philosophie indique que l'outil doit faire une seule tâche, la faire bien, et communiquer avec l'extérieur via stdin/stdout, entres autres?).
Après, malgré que je sois moi-même plutôt contre systemd, il faut reconnaître que c'est un outil qui a eu plusieurs mérites:
Tout ça, c'est lié, et sysVinit ne le fait pas. Rc.d non plus.
Le chien de garde (watchdog), est notamment une fonctionnalité utile quand on commence a vouloir des systèmes autonomes qui s'auto-réparent (dans les limites du faisable). Oui, ça veut dire qu'il est souhaitable qu'un service qui tombe redémarre tout seul (pour éviter de cramer du fioul sur 400Km juste pour faire un redémarrage, par exemple).
C'est faisable avec runit (et les daemontools de manière générale) mais ce n'est pas a franchement parler efficace, en pratique on laisse le travail de gérer les dépendances aux daemons eux-mêmes. Je le sais: je l'ai fait.
Ce simple fait indique que les daemons ne peuvent, de facto, pas faire "une seule chose et la faire bien", et ça encourage a hard-coder la dépendance à un truc tiers, donc a réduire le choix de l'admin pour ses outils.
De ce point de vue, systemd est plus UNIX que sysVinit+rc.d, qu'il a remplacés sur de nombreux systèmes.
Pour ce qui est de la gestion des journaux, il n'est pas impossible que si l'on ne s'était pas farci sysVinit+rc.d pendant des décennies, les daemons auraient adopté plus tôt un comportement plus générique, c'est à dire: émettre par défaut sur stdout ou stderr, en laissant au gestionnaire de services le soin de les rediriger et traiter ou il faut, au lieu de s'appuyer sur syslog, qui est un outil unique pour toutes les instances, fait qui implique que s'il tombe, est corrompu, ou autre, on perds potentiellement tous les logs.
On peut également citer le double-fork-trick.
Encore une fois, systemd (et ici daemontools et ses héritiers le font aussi bien) est largement plus UNIX que les outils qu'il a permis de remplacer.
Moi, bien que je n'aime pas du tout systemd, je lui suis reconnaissant: sans systemd et les problèmes autour, je n'aurai jamais su qu'il était possible aussi simplement de s'affranchir de sysVinit+rc.d, je n'aurai probablement jamais (ou alors bien plus tard) trouvé runit, mon init+gestionnaire de services actuel.
Systemd a beau être une usine à gaz, un monstre de complexité, un framework alors que je préfère les bibliothèques, avoir eu des failles de sécurité réseau... je le trouve malgré tout largement préférable à la situation dont il nous a sortis.
En fait, ironiquement, c'est grâce à systemd que certaines distro, dont debian, ont commencé à supporter plusieurs systèmes d'init pour de vrai (le support des init autres que sysVinit+rc.d dans Debian reste parcellaire, soit, mais avant c'était le vide inter-sidéral).
Et le pire dans tout ça, c'est que malgré mon discours ici plutôt en faveur de systemd, ben, je refuse toujours de l'utiliser, pour mes raisons propres (un init qui dépend de dbus est le genre de trucs qui me chatouillent un peu par exemple).