Re: Debian 8 bientôt publiée !

[Lucas Nussbaum <lucas@debian.org>]

On 08/04/15 at 13:48 +0200, BERTRAND Joël wrote:
> Lucas Nussbaum a écrit :
> >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).
> 
> 	Rien à voir. systemd est le premier truc appelé par le noyau. S'il plante
> (et il a un paquet de raison pour planter), tout le système est en carafe
> sauf à reboote avec un init=/bin/bash. J'ai donné plus souvent qu'à mon
> tour.

As-tu ouvert des bugs pour les différents problèmes que tu as rencontré
avec systemd ?

> >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 ?
> 
> 	Je n'ai jamais dit cela. Je trouve qu'un système comme init SysV est bien
> plus efficace parce qu'il lance dans des espaces mémoire différents les
> différents daemons.

Cette phrase ne veut rien dire.
1) systemd et sysvinit lancent tous deux les différents daemons dans des
espaces mémoires différents. C'est la base de ce qu'est un processus.
2) en fait, en général, c'est moins efficace de séparer les espaces
mémoires. C'est pour ça qu'on fait des threads, et aussi pour ça que GNU
Hurd a du mal à concurrencer Linux ;)

> Init SysV étant simple, il est facilement correctible en
> cas de problème. Lorsque systemd se viande, il est très difficile de voir
> pourquoi et de corriger les problèmes.

Je ne nie pas que systemd soit plus difficile à appréhender que
sysvinit, qu'il y a besoin de se former, et que ça n'est pas forcément
évident.

> >>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.)
> 
> 	Sauf que je veux bien avoir des logs binaires (même si je trouve cela
> idiot). Lire des logs binaires, c'est bien lorsque le système est démarré et
> actif. Lorsqu'il se viande au boot, et que tu n'as sous la main qu'un shell,
> les logs en clair visualisables par un simple more ou less, c'est vraiment
> bien. On peut utiliser tous les outils système, ce qui n'est vraiment pas le
> cas avec un format binaire.

1) si tu n'as pas désactivé la redirection vers syslog, tu as toujours
les logs texte. Tu peux très bien ignorer complètement journald.
2) Etant donné que journalctl est dans /bin, je ne vois pas vraiment de
situation où tu ne pourrais pas consulter tes logs. Tu peux toujours les
transférer vers une autre machine et utiliser le journalctl d'une autre
machine (avec --file=).

> >>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=)
> 
> 	J'aimerais bien savoir comment. Une fois que syslogd est lancé,
> certainement. Mais pour les premières traces de systemd, tu repasseras.

De quelles traces parles-tu ? Pour voir les [OK]/[FAILED], il faut
enlever le paramètre quiet de la ligne de commande du noyau.
Mais de toute façon, la manière la plus simple de voir quels services
sont démarrés ou pas est "systemctl" ou "systemctl status" (qui n'a pas
d'équivalent avec sysvinit).

Et sinon, tous les messages de log arrivent bien dans journald et
syslog. Si tu as un contre-exemple, je suis intéressé.

> >>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.
> 
> 	Cette commande doit au minimum être automatisée.

Voir https://bugzilla.redhat.com/show_bug.cgi?id=615527
et https://bugs.freedesktop.org/show_bug.cgi?id=69096
sur pourquoi ce n'est pas si simple de l'automatiser.

> 	Comme il faudra encore une
> fois que les devs du bloatware s'arrangent pour corriger les lancements des
> services. Je ne vois pas pourquoi /etc/init.d/nfs-kernel-server start est
> redirigé vers les scripts systemd alors que /etc/init.d/ntp start ne le fait
> pas. Et encore, ce n'est qu'un truc sur lequel je suis tombé ce matin (aucun
> des deux scripts en question n'a été modifié).

Hum, avec jessie:
lucas@grep:~$ sudo /etc/init.d/ntp restart
[ ok ] Restarting ntp (via systemctl): ntp.service.
lucas@grep:~$ sudo /etc/init.d/nfs-kernel-server restart
[ ok ] Restarting nfs-kernel-server (via systemctl): nfs-kernel-server.service.

Ou j'ai mal compris ton problème ?

(Note que a priori, s'il y a un problème, c'est un bug Debian, pas un bug systemd)

> >>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.
> 
> 	Sur un serveur, n peut être assez grand. Ça fait beaucoup de lignes
> d'erreurs dans les logs.

En fait, je pense que je ne comprends pas de quoi tu parles. D'un côté, tu
parles de la complexité de l'algo de calcul des dépendances entre services, et
je fais remarquer que même avec un algo en n^2, ce n'est pas forcément très
grave si n reste petit. De quels essais successifs parles-tu ?

> >>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.
> 
> 	Heureux homme. J'ai migré des serveurs en systemd parce que soit-disant
> c'est l'avenir. J'en suis à avoir la trouille d'appliquer les patches aux
> systèmes parce que je ne sais jamais quelle sera la réaction de systemd. La
> plupart du temps, il faut un redémarrage pour être sûr du bon fonctionnement
> de la chose. C'est assez pénible.
> 
> 	Par ailleurs, systemd a une dépendance forte sur udev et sur le noyau... Il
> n'y a pourtant aucune raison.

(soupir) si, plein de raisons. Notamment les cgroups (voir ci-dessous).

> >>	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.
> 
> 	J'aimerais bien que tu m'expliques lesquels.

Un problème assez classique, c'est un service qui démarre un processus fils
(apache qui démarre un CGI, par exemple). Et où l'arrêt propre du service
n'arrête pas les processus fils, qui continuent de tourner. Ou pire, un service
qui démarre un processus fils, qui lui-même démarre un processus fils. Si le
deuxième processus fils ne se termine pas, mais que le premier se termine, il
n'y a plus aucun moyen (hors cgroups) de savoir que ce fils vient en fait du
service. Tout ça est lié au fait que le ppid d'un processus dont le père meurt
n'est pas son grand-père, mais init. Donc on perd l'information sur la
filliation des processus. C'est (entre autres) à ça que servent les cgroups
dans systemd.

Lucas