Topic: services
-
rc.conf, sysrc and service on FreeBSD: enabling, starting and checking what runs at boot
FreeBSD services are enabled declaratively by an rc.conf variable (in /etc/rc.conf or a per-service file in /etc/rc.conf.d); sysrc and service <name> enable both just write that variable, and rc.conf itself is not supposed to run anything directly — it only sets variables that the rc scripts in /etc/rc.d read. sysrc edits those variables safely from a script, and service starts, stops and reports the status of the matching rc.d script.
-
Managing AIX services with the System Resource Controller: lssrc, startsrc/stopsrc, and rc.tcpip
AIX manages long-running daemons through the System Resource Controller (SRC), a subsystem/group model configured in the ODM's SRCsubsys object class, not systemd units. lssrc/startsrc/stopsrc drive it interactively, while /etc/inittab and scripts like rc.tcpip control what starts automatically at boot.
-
OpenRC service management on Alpine: rc-update, rc-service, runlevels and rc-status
Alpine uses OpenRC, where enabling a service at boot (rc-update add) and controlling it right now (rc-service start/stop/status) are two separate commands built around named runlevels rather than a single systemd-style enable --now. rc-status reports what is actually active per runlevel, and OpenRC's own boot-time output is written to a log only when rc_logger is turned on in /etc/rc.conf.
-
Service startup type and crash recovery: Set-Service plus sc.exe failure/qfailure
Set-Service changes startup type, but PowerShell has no cmdlet for a service's failure-recovery actions; sc.exe failure and sc.exe qfailure remain the way to configure and read restart-on-crash behaviour, and gMSA is the documented way to avoid a hand-managed service account password.
Machine-readable: JSON