Gestionnaires de services comparés : systemd, launchd, Service Control Manager, SRC et rc.d/OpenRC

Ce que c'est

Chaque système d'exploitation généraliste fournit un superviseur qui démarre et arrête les services, rend compte de leur état et, en règle générale dans une opération distincte, les relance au démarrage suivant. Sous macOS, LABEL désigne le label du job, tel que défini dans son plist.

Tâche	Linux (systemd)	macOS (launchd)	Windows (SCM)	AIX (SRC)	FreeBSD (rc.d)	Alpine (OpenRC)
Démarrer	systemctl start NAME	launchctl kickstart system/LABEL (-k redémarre une instance en cours d'exécution)	Start-Service NAME	startsrc -s NAME	service NAME start	rc-service NAME start
Arrêter	systemctl stop NAME	launchctl bootout system/LABEL (décharge le job ; son plist est rechargé au boot, sauf si launchctl disable a été exécuté)	Stop-Service NAME	stopsrc -s NAME	service NAME stop	rc-service NAME stop
Statut	systemctl status NAME	launchctl print system/LABEL	Get-Service NAME	lssrc -s NAME	service NAME status	rc-service NAME status
Activer au boot	systemctl enable NAME	installer un plist dans /Library/LaunchDaemons avec RunAtLoad, puis launchctl bootstrap system PATH	Set-Service NAME -StartupType Automatic	enregistrer le sous-système avec mkssys, puis ajouter une entrée startsrc dans /etc/inittab (mkitab) ou /etc/rc.tcpip	sysrc NAME_enable=YES (écrit dans /etc/rc.conf)	rc-update add NAME default
Lire le journal	journalctl -u NAME	log show --predicate 'process == "NAME"'	Get-WinEvent -LogName System (événements de démarrage et d'arrêt du Service Control Manager) et -LogName Application (événements propres au service)	errpt, ou le fichier syslog indiqué dans /etc/syslog.conf (rien n'y est journalisé tant que ce n'est pas configuré)	via syslog, en général /var/log/messages	via syslog, en général /var/log/messages

Pourquoi c'est important

« Activé » et « en cours d'exécution » sont deux états indépendants sur chacun de ces systèmes. Un agent qui n'en modifie qu'un seul laisse un service qui soit s'arrête au prochain redémarrage, soit n'a jamais été lancé une première fois. systemctl enable crée un lien symbolique mais ne démarre rien ; Windows rend cette distinction explicite avec le paramètre dédié -StartupType ; depuis macOS 10.10, launchd sépare le chargement de la définition d'un job (bootstrap) de son exécution ponctuelle (kickstart) ; sous FreeBSD, rc.conf détermine le démarrage au boot tandis que service pilote l'instance en cours d'exécution.

Comment l'appliquer

• Relancer la commande de statut après chaque modification : « démarré » n'implique pas « activé ».
• Sous macOS, launchctl load -w fonctionne encore sur les versions actuelles, mais il est remplacé par les sous-commandes bootstrap/bootout/enable/disable/kickstart ; privilégier celles-ci dans les nouveaux scripts.
• Sous AIX, seuls les démons enregistrés auprès du System Resource Controller via mkssys répondent à startsrc/stopsrc/lssrc.
• Toutes les commandes, à l'exception des requêtes de statut, exigent les droits root (sudo) ou une session PowerShell élevée ; le domaine system/ de macOS exige toujours sudo. Exécuté sans les droits root, systemctl peut s'arrêter sur une invite interactive de mot de passe polkit ; il faut donc utiliser sudo -n dans les exécutions non interactives.

Pièges

• rc.d de FreeBSD et OpenRC d'Alpine sont deux implémentations différentes : sysrc n'existe pas sous Alpine et rc-update n'existe pas sous FreeBSD.
• Set-Service -StartupType Disabled ne modifie que le comportement au boot ; un service en cours d'exécution continue de tourner jusqu'à son arrêt. L'arrêt d'un service dont dépendent d'autres services en cours d'exécution échoue, sauf si Stop-Service -Force (ou, dans PowerShell 7, Set-Service -Status Stopped -Force) arrête également les services dépendants.
• journalctl -u NAME ne renvoie rien pour un service qui écrit dans son propre fichier de log au lieu du journal.