systemd forking vs simple ?

Lorsque vous démarrez le service manuellement à partir de la ligne de commande (sans utiliser la commande nohup ou la commande de préfixe & pour l'exécuter en arrière-plan, ou en d'autres termes, il suffit d'exécuter la commande que vous mettriez dans le fichier ExecStart= ligne de la .service ), que se passe-t-il ?

a) Si le service démarre et continue à fonctionner, et que l'invite ne revient pas jusqu'à ce que vous appuyiez sur Control-C ou que vous arrêtiez le service d'une autre manière : alors Type = simple (o Type = exec si votre version de systemd l'a) est le bon choix.

La différence pratique entre Type = simple y Type = exec est surtout dans la détection des erreurs : Type = simple procédera à d'autres tâches dès que systemd aura fork() a créé un nouveau processus pour lui, et il peut donc permettre à des choses dépendantes de se dérouler même si l'invocation du processus réel de la Exec= échoue. D'autre part, Type = exec vérifiera le Exec= est effectivement invoquée avec succès et signale un échec dans le cas contraire.

Donc, si votre systemd est suffisamment récent pour supporter le Type = exec vous préférerez peut-être l'utiliser plutôt que Type = simple pour une meilleure vérification des erreurs. Mais si vous avez besoin que le démarrage se fasse le plus rapidement possible, et que la détection rapide de l'échec du démarrage de votre service n'est pas essentielle, et/ou si vous souhaitez être compatible avec les anciennes versions de systemd vous pouvez toujours utiliser Type = simple .

b) Si l'invite revient mais que le service continue de fonctionner en arrière-plan (c'est-à-dire que le service se démonétise tout seul), alors Type = forking est le bon choix.

c) Si le service fait son travail et retourne à l'invite sans rien laisser s'exécuter (c'est-à-dire que le service se contente d'ajuster certains paramètres du noyau, d'envoyer une commande à quelque chose d'autre ou de faire quelque chose de similaire), alors Type = oneshot est probablement le bon choix. Dans ce cas, ExecStart du service pourrait être l'ordre de "régler" quelque chose, et ExecStop serait la commande correspondante pour le "déverrouiller". Ce type bénéficie généralement de RemainAfterExit=true Ainsi, systemd conservera l'"état" de ce service en fonction du dernier "set" ou "unset".

L'autre Type sont des cas particuliers. Par exemple, si le service utilise une connexion D-Bus, alors Type = dbus pourrait être le meilleur choix. Il fait systemd conscient de ce fait, et ensuite systemd suivra ce service (et tout ce qui en dépend) par la présence de ce service sur le D-Bus.

Pour utiliser Type = notify le processus doit pouvoir se connecter au socket Unix spécifié dans la variable d'environnement $NOTIFY_SOCKET et de signaler son état en écrivant des messages à cette socket chaque fois que nécessaire. De plus, le fichier de service doit spécifier l'option NotifyAccess pour accorder l'accès à la prise de notification comme il convient.

Il existe un utilitaire de ligne de commande systemd-notify et une fonction de la bibliothèque C sd_notify(3) que vous pouvez utiliser pour envoyer ces messages, mais si aucun d'entre eux ne convient à vos besoins, vous pouvez simplement implémenter votre propre expéditeur de messages. Les messages requis sont très simples, et ressemblent à des affectations de variables Shell : par exemple, pour notifier que le service a terminé avec succès le démarrage et est prêt à servir toutes les demandes entrantes, le service doit envoyer la chaîne équivalente à la sortie de printf "READY=1\n" à la prise. Voir man 3 sd_notify pour plus de détails sur les messages reconnus.

Note : de nombreuses applications de service conçues pour être portables sur de nombreux systèmes de type Unix peuvent se comporter comme b) par défaut, mais peuvent être amenées à fonctionner comme a) en ajoutant une option (généralement décrite comme "don't fork", "keep running in foreground", "don't daemonize" ou similaire). Dans ce cas, si l'option n'a pas d'autres effets secondaires, alors l'ajout de l'option et l'utilisation d'un comportement de type a) seraient préférables pour les applications suivantes systemd .