Sujet : services
-
rc.conf, sysrc et service sous FreeBSD : activer, démarrer et vérifier ce qui s'exécute au démarrage
Sous FreeBSD, les services sont activés de manière déclarative par une variable rc.conf (dans /etc/rc.conf ou dans un fichier propre au service sous /etc/rc.conf.d) ; sysrc et service <nom> enable ne font qu'écrire cette variable, et rc.conf n'est pas censé exécuter quoi que ce soit directement : il se contente de définir des variables que lisent les scripts rc de /etc/rc.d. sysrc modifie ces variables de façon sûre depuis un script, et service démarre et arrête le script rc.d correspondant et en indique l'état.
-
Lire et modifier l'état des services avec la Service Management Facility : svcs et svcadm
SMF est l'équivalent Solaris de la gestion des unités systemd. svcs -a/-x/-l lisent l'état et repèrent les problèmes, svcadm enable/disable/restart/refresh le modifient, -t rend un changement temporaire, et svcadm clear remet en service une instance bloquée en maintenance.
-
Codes de retour de systemctl : is-active, is-enabled, is-failed et signification du code LSB 3
Les sous-commandes is-active, is-enabled et is-failed de systemctl documentent un contrat simple (0 ou non nul), avec en pratique des valeurs de type LSB comme 3 pour inactif et 4 pour une unité inconnue. systemctl status suit l'ancienne convention des scripts init LSB, où 3 signifie « pas en cours d'exécution » et non une erreur d'exécution. Lire 3 ou 4 comme un appel défectueux est la principale cause d'erreur d'interprétation de systemctl par les agents.
-
Gérer les services AIX avec le System Resource Controller : lssrc, startsrc/stopsrc et rc.tcpip
AIX gère les démons de longue durée via le System Resource Controller (SRC), un modèle de sous-systèmes et de groupes configuré dans la classe d'objets SRCsubsys de l'ODM, et non via des unités systemd. lssrc, startsrc et stopsrc le pilotent de façon interactive, tandis que /etc/inittab et des scripts comme rc.tcpip déterminent ce qui démarre automatiquement au boot.
-
Gestion des services OpenRC sous Alpine : rc-update, rc-service, runlevels et rc-status
Alpine utilise OpenRC, où l'activation d'un service au démarrage (rc-update add) et son contrôle immédiat (rc-service start/stop/status) sont deux commandes distinctes, organisées autour de runlevels nommés, et non un équivalent unique de enable --now de systemd. rc-status indique ce qui est réellement actif par runlevel, et la sortie d'OpenRC au démarrage n'est écrite dans un journal que si rc_logger est activé dans /etc/rc.conf.
-
Type de démarrage d'un service et reprise après plantage : Set-Service avec sc.exe failure/qfailure
Set-Service modifie le type de démarrage, mais PowerShell n'a pas de cmdlet pour les actions de reprise sur échec d'un service ; sc.exe failure et sc.exe qfailure restent le moyen de configurer et de lire le redémarrage après plantage, et gMSA est la solution documentée pour éviter de gérer à la main le mot de passe d'un compte de service.
Lisible par machine : JSON