Re: Debian 8 bientôt publiée !
Lucas Nussbaum a écrit :
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 ?
La réponse est 'oui'.
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 ;)
Cette phrase signifie pourtant quelque chose. Et si Hurd n'arrive pas à
concurrencer Linux, c'est surtout parce que le micronoyau sous Hurd est
une bouse par rapport à l'état de l'art (L4 entre autres) et que
l'équipe de développement est toute petite. Mais ce n'est pas le sujet.
Init SysV est un mécanisme rudimentaire qui lance des scripts. Ces
scripts sont démarrés par un execve() ou équivalent dans un espace
mémoire propre à chaque script. Ils peuvent se vautrer sans compromettre
le système. Avec systemd, ce n'est pas le cas. Il y a toute une
tripaille de mécanisme avant d'arriver au lancement du script.
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.
Ce n'est pas une question de formation. Le fait de remplacer un
mécanisme simple par une usine-à-gaz avec des fuites non exempte de bugs
du fait de sa conception ne facilite pas les choses.
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=).
Je n'ai pas dit que tu ne pouvais pas. Simplement, ce n'est pas
pratique et ce n'est pas la configuration par défaut.
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).
Ah bon ? Première nouvelle. Ce n'est pas parce que la plupart des
scripts d'init ne le propose pas que cela n'existe pas.
/etc/init.d/mon_daemon status peut tout à fait être disponible. Quant à
la sortie de systemctl status, elle est assez amusante puisque tu peux
avoir en même temps "active", "running" et "exited"... J'ai eu le coup
ce matin avec ntpd.
Et sinon, tous les messages de log arrivent bien dans journald et
syslog. Si tu as un contre-exemple, je suis intéressé.
La configuration par défaut de systemd.
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.
Problème de conception du bloatware.
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)
Raté, c'est un bug systemd (et non, je n'ai pas fait de BR).
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 ?
Je pense surtout que tu n'as jamais mis les mains dans le cambouis
systemd. Si tu avais eu a dépatouiller des configurations qui ne
bootaient plus après la migration systemd, tu verrais de quoi je parle.
Je me contrefiche que l'algorithme en question soit en n**2, en n**3 ou
en n**ce_que_tu_veux. Mais lorsque tu dois débrouiller un système qui
merdoie en raison de dépendances non traitées et que tu dois chercher
dans les logs pourquoi tel daemon ne démarre pas correctement, tu es
très content d'avoir des fichiers journaux caviardés de 'failed'.
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).
Non. Les cgroups existent depuis assez longtemps pour ne pas avoir une
dépendance aussi forte. Aujourd'hui, on a l'impression de retourner dans
le grand monde Windowzien où il faut rebooter à chaque mise à jour pour
être vraiment sûr que tout refonctionne.
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.
Je reformule un peu (tu ne m'en voudras pas). Ce genre de chose, on
sait faire depuis pas mal de temps, mais il faut le gérer.
Effectivement, si le cas n'est pas traité, c'est init qui récupère le
processus en question. Mais ce n'est en aucun cas un fonctionnement
normal. En gros, tu me dis que systemd obvie à l'indigence des
développeurs de daemons qui ne veulent pas traiter ce cas.
À l'extrême limite, avec systemd, on peut récupérer un processus qui ne
devrait plus tourner.
JKB
Reply to: