Euh, juste non. SysV a un vrai problème pour surveiller les services de manière fiable.
Et pour cause, c'est pas son job. Regarde plutôt du coté de runit ou daemontools.
Sans compter que SysV s'attend à ce que chaque script réimplémente la même chose (le fait de se mettre en daemon, d'être compatible avec le LSM du jour, etc...)
Non plus, SysV init s'attend juste à ce que le process rende la main. Ca peut être fait de pleins de façons différentes, la plus courante étant la daemonisation via double fork, mais c'est loin d'être la seule (hint : bsd).
Après pour simplifier la maintenance et avoir un peu cohérence dans les scripts, des templates ont été créés. Ils ne sont ni nécessaires ni forcément pertinents.
Sérieusement, SysV ou Upstart, c'était vachement plus cassé que systemd.
C'est une question de point de vue. Voici une petite liste de choses cassées dans systemd
- Logs centralisés distants sans I/O locaux (on peut configurer un syslog pour qu'il rebalance les logs à distance, mais pas rediriger les logs directement sur le réseau)
- Chiffrement non LUKS (c'est à dire juste les banques, l'armée et pas mal de matos médical - une paille en terme de clients pros, et je laisse de coté les éditeurs propriétaires qui pensent qu'en réinventant la roue leur appli sera mieux protégée)
- cgroups (oui, oui on peut vouloir faire autres choses avec les cgroups que ce que systemd à décidé - voire le nombre de patch à ce sujet dans docker pour comprendre)
- services dynamiques (ie services lancés - éventuellement par un autre service - avec une floppée de paramètres pour le configurer dynamiquement)
- contrôle de services par utilisateur sans droits root (avec SE Linux pour l'instant on ne peut qu'élever les droits d'un utilisateur pour lui donner un accès root au dbus "system")
- initialisation synchrone de périphériques (parfois nécessaire par exemple si il faut initialiser une carte avant de pouvoir initialiser le matos qui est derrière) - en cours de correction, mais je sens que le bébé va être refilé au kernel.
Toute ces choses (et de nombreuses autres) marchent très bien dans upstart, sysV init, runnit, daemontools, rc.d, openrc etc.
Il se trouve que dans certains environnements les fonctions citées plus haut sont absolument nécessaires.
Je suis content pour toi si systemd résout tes problèmes, mais il est loin d'être iso-fonctionnel avec les inits historiques et il ne prend pas vraiment le bon chemin pour le devenir.
[^] # Re: C'est là tout le problème
Posté par Kaane . En réponse au journal systemd: je me lance. Évalué à 4.
Euh, juste non. SysV a un vrai problème pour surveiller les services de manière fiable.
Et pour cause, c'est pas son job. Regarde plutôt du coté de runit ou daemontools.
Sans compter que SysV s'attend à ce que chaque script réimplémente la même chose (le fait de se mettre en daemon, d'être compatible avec le LSM du jour, etc...)
Non plus, SysV init s'attend juste à ce que le process rende la main. Ca peut être fait de pleins de façons différentes, la plus courante étant la daemonisation via double fork, mais c'est loin d'être la seule (hint : bsd).
Après pour simplifier la maintenance et avoir un peu cohérence dans les scripts, des templates ont été créés. Ils ne sont ni nécessaires ni forcément pertinents.
Sérieusement, SysV ou Upstart, c'était vachement plus cassé que systemd.
C'est une question de point de vue. Voici une petite liste de choses cassées dans systemd
- Logs centralisés distants sans I/O locaux (on peut configurer un syslog pour qu'il rebalance les logs à distance, mais pas rediriger les logs directement sur le réseau)
- Chiffrement non LUKS (c'est à dire juste les banques, l'armée et pas mal de matos médical - une paille en terme de clients pros, et je laisse de coté les éditeurs propriétaires qui pensent qu'en réinventant la roue leur appli sera mieux protégée)
- cgroups (oui, oui on peut vouloir faire autres choses avec les cgroups que ce que systemd à décidé - voire le nombre de patch à ce sujet dans docker pour comprendre)
- services dynamiques (ie services lancés - éventuellement par un autre service - avec une floppée de paramètres pour le configurer dynamiquement)
- contrôle de services par utilisateur sans droits root (avec SE Linux pour l'instant on ne peut qu'élever les droits d'un utilisateur pour lui donner un accès root au dbus "system")
- initialisation synchrone de périphériques (parfois nécessaire par exemple si il faut initialiser une carte avant de pouvoir initialiser le matos qui est derrière) - en cours de correction, mais je sens que le bébé va être refilé au kernel.
Toute ces choses (et de nombreuses autres) marchent très bien dans upstart, sysV init, runnit, daemontools, rc.d, openrc etc.
Il se trouve que dans certains environnements les fonctions citées plus haut sont absolument nécessaires.
Je suis content pour toi si systemd résout tes problèmes, mais il est loin d'être iso-fonctionnel avec les inits historiques et il ne prend pas vraiment le bon chemin pour le devenir.