Re: Debian 8 bientôt publiée !
On 08/04/15 at 11:10 +0200, BERTRAND Joël wrote:
> Lucas Nussbaum a écrit :
> >Note qu'une force de systemd dans ce contexte est qu'écrire un fichier
> >service est beaucoup plus simple et rapide qu'écrire un script d'init,
> >vu qu'une grosse partie de la complexité est gérée par systemd au lieu
> >du script d'init. systemd simplifie aussi l'écriture des daemons,
> >puisqu'il n'y a plus besoin de forker, d'écrire des fichiers pid, de
> >gérer syslog, etc. (C'est lié à un des arguments des détracteurs de
> >systemd: "puisqu'il n'y a plus besoin de s'embeter avec ça, les daemons
> >vont arrêter de le faire, et ça ne marchera plus avec sysvinit").
>
> Je gros problème est surtout que systemd est un point unique de plantage
Je ne comprends pas cet argument:
Oui, systemd est un assez gros logiciel (même s'il y a en a plus gros
qui sont aussi critiques, comme le noyau). Mais à la limite, le fait que
ce soit un gros logiciel englobant rend plutot la résolution de bugs
plus facile, puisqu'il y a moins de problèmes d'interactions avec
d'autres logiciels extérieurs. Est-ce que ça serait mieux si à la place
de systemd, on avait une douzaine de petits logiciels avec la même
fréquence de plantage ?
> qui balance ses logs dans un fichier journal en binaire
Là non plus, je ne comprends pas pourquoi c'est un problème. On utilise
plein de formats binaires tous les jours. Les systèmes de fichiers
utilisent un format binaire. Les systèmes de gestion de base de données
aussi. Et pourtant, on n'entend personne dire qu'avoir un format binaire
pour les dentries est trop dangereux, ou qu'il faudrait un backend CSV
dans postgresql.
(Et on utilise aussi plein de formats texte qui ne sont pas
particulièrement robustes à la corruption. Par exemple JSON.)
> et qu'il faut penser
> à lui demander aussi de bien vouloir les balancer dans syslog.
... ce qui est le comportement par défaut. (configurable dans
journald.conf, avec ForwardToSyslog=)
> Avec un
> démarrage de type SysV, il était vraiment rare de tout foirer et d'empêcher
> le démarrage d'une machine. Avec systemd, j'ai déjà eu de très mauvaises
> surprises (jusqu'à un segfault de systemd qui m'a permis d'aller en urgence
> en salle blanche à l'autre bout de Paris pour récupérer une machine !).
> L'autre problème est qu'il surcharge les scripts d'init par ses propres
> scripts et qu'il ne les lit pas dynamiquement (pour le coup, ce ne serait
> pas difficile à implanter avec un truc aussi trivial qu'une somme de
> hashage).
Tu cherches peut-être "systemctl daemon-reload" ? Ou alors, je n'ai pas
compris ton problème.
> Bref, pour valider un truc avec systemd, il vaut mieux redémarrer
> plutôt que de tester un script pour être sûr que ça passe. C'est un progrès.
>
> Je suis aussi assez stupéfié de la façon dont le bloatware gère les
> dépendances. L'algorithme est en n**2 avec essais successifs.
[citation needed]. Mais même si c'est le cas, vu que 'n' est petit, je
ne vois pas le problème.
> C'est d'une
> efficacité redoutable et permet de bien voir ce qui foire et ce qui
> fonctionne normalement puisque les logs sont constellés de 'failed'.
Ce n'est pas mon expérience.
> Même l'argument des cgroups ne tient pas puisqu'il est parfaitement
> possible (redhat le faisait depuis au moins la version 6 qui doit dater du
> dernier millénaire et debian le faisait aussi depuis longtemps) de fournir
> un script de base pour le lancement des daemons qui s'occupait justement de
> cela (à savoir fork, enregistrement du PID et j'en passe).
Effectivement, on peut s'en sortir dans certains cas simples ainsi, mais
il y a plein de cas pénibles où cette méthode ne suffit pas.
Lucas
Reply to: