Re: Debian 8 bientôt publiée !
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.
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. 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.
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.
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.
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. 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é).
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.
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.
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.
JKB
Reply to: