[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Jessie et habitude vis à vis de systemd



On 12/05/15 at 21:50 +0200, Christophe Mehay wrote:
> Je me permets de répondre car je souhaiterais apporter quelques précisions
> sur la raison pour laquelle unbound ici n'affiche pas d'erreur.
> 
> Je pense que vous vous fourvoyez sur la façon dont systemd démarre les
> services, il n'y a pas de binaire compatible ou non avec systemd, la réalité
> c'est qu'un service initialisé avec systemd doit dans l'idéal ne pas forker
> lui-même,

Non, systemd supporte les deux cas (fork avec Type=forking, pas de fork
avec Type=simple). La motivation forte pour ne pas forker, c'est que ce
n'est pas forcément utile, donc autant ne pas le faire. Mais on a vu
dans cette discussion qu'utiliser Type=forking fournissait une manière
peu chère de signaler qu'une partie de l'initialisation du service
s'était bien passée, notamment pour détecter des problèmes de
configuration.

Mais c'est loin d'être parfait: le service pourrait très bien lire sa
config après avoir forké. Et il y a des opérations d'initialisation qui
sont souvent faites après le fork, par exemple ouvrir le port réseau du
service.  S'il y a un autre service qui écoute sur le port, ça serait
alors non détecté.

Du coup, la vraie solution, c'est utiliser /socket activation/, ou
Type=notify, pour que le service soit vraiment opérationnel à la fin de
son démarrage.

> et dans le cas présent, unbound n'utilise pas un service systemd
> mais le script de sysvinit démarré via systemd.
> 
> Le soucis que l'on a avec ce système, c'est que systemd n'a plus de pid du
> processus attaché à lui-même, et il ne se contente que d'exécuter le script
> qui va forker unbound avec start-stop-daemon unbound.
> 
> Pour systemd, le script a bien été exécuté et il a quitté correctement vu
> que c'est ce qu'on lui a demandé de faire.
> 
> Le problème vient ici du fait que le mainteneur n'a pas fait de fichier
> .service conforme pour unbound mais a préféré utiliser le script de sysvinit
> au dessus de systemd, ce qui fonctionne dans le meilleur des cas, mais qui
> n'est pas correcte.

Oui et non. Pour utiliser les scripts sysv, systemd génère à la volée
des fichiers .service englobant le script d'init (visible avec systemctl
cat unbound). Et il le fait plutôt bien (gestion des en-têtes LSB, des
dépendances, etc, cf
http://www.freedesktop.org/software/systemd/man/systemd-sysv-generator.html).

Utiliser un fichier .service ne réglerait vraiment le problème que si le
service n'utilise pas Type=simple, mais ce n'est pas forcément simple ;)
Voir une discussion sur le cas de sshd (qui utilise type=simple, ce qui
empêche de détecter au lancement des erreurs de configuration):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778913#30

Lucas


Reply to: