La commande "systemctl (re)start foo" envoie maintenant une requête au PID1 qui va se charger de (re)démarrer le daemon.
Ça peut avoir de l'importance par exemple pour les variables d’environnement et SELinux. Pour le moment si un utilisateur appelle directement l'initscript, des variables d’environnement peuvent se propager dans l’environnement du daemon, avec systemd ce n'est plus possible. Pour SELinux le daemon est toujours démarré depuis le contexte du init ça évite donc les risque que le domaine du daemon soit incorrect.
[^] # Re: systemday
Posté par Bigon . En réponse à la dépêche Red Hat Enterprise Linux 7. Évalué à 7.
La commande "systemctl (re)start foo" envoie maintenant une requête au PID1 qui va se charger de (re)démarrer le daemon.
Ça peut avoir de l'importance par exemple pour les variables d’environnement et SELinux. Pour le moment si un utilisateur appelle directement l'initscript, des variables d’environnement peuvent se propager dans l’environnement du daemon, avec systemd ce n'est plus possible. Pour SELinux le daemon est toujours démarré depuis le contexte du init ça évite donc les risque que le domaine du daemon soit incorrect.