Reading and changing service state with the Service Management Facility: svcs and svcadm

Goal

Determine the state of services on a Solaris 11.4 host and safely enable, disable, restart or clear a service instance using the Service Management Facility (SMF).

Prerequisites

A shell in the zone whose services you manage — each non-global zone runs its own SMF instance and is administered from inside that zone — with rights to manage services (the root role or a profile with the relevant SMF authorization — see the RBAC article in this series). Reading state is unprivileged.

Steps

1. List everything: svcs -a shows every service instance with its state (online, offline, disabled, maintenance, degraded, legacy_run) and its fault management resource identifier (FMRI).
2. Find problems fast: svcs -x prints an explanation only for instances that are enabled but not running, or that have unsatisfied dependencies; it produces no output if everything enabled is running.
3. Inspect one instance in depth: svcs -l <fmri> prints dependencies, the process contract, and the log path for that instance; svcs -L <fmri> prints only the log path.
4. Enable persistently: svcadm enable <fmri>. By default, enable is persistent across reboot; add -t to enable only temporarily, until the next reboot.
5. Disable, restart or refresh: svcadm disable [-t] <fmri> (persistent unless -t); svcadm restart <fmri> (stop plus start; it acts only on online or degraded instances, so it does nothing for one in maintenance); svcadm refresh <fmri> (copies the current configuration into the running snapshot and runs the refresh method, if any). -t exists only for enable and disable; add -s to wait until the instance settles.
6. Read logs for a failing instance from the path svcs -l reported, normally a file under /var/svc/log/ named after the service's FMRI.
7. Clear a stuck instance: once the underlying problem is fixed, svcadm clear <fmri> returns an instance from maintenance or degraded state so the restarter re-evaluates it.

Expected result

svcs -x produces no output when every enabled service is actually running; the target instance shows online (or disabled, if that was the goal) in svcs -a, and its log file stops accumulating the earlier error.

Limits and test basis

svcadm enable/disable -t changes are lost on the next reboot by design — do not rely on -t for anything that must survive a restart; drop -t once you know the change is correct. Clearing a maintenance instance does not fix the underlying cause: if the start method still fails, the instance returns to maintenance immediately, so treat a clear that doesn't hold as a sign to read the log, not to clear again. State changes are reversible by re-running svcadm in the opposite direction, but not always from where you stand: disabling or restarting network/ssh, network/physical or a service they depend on can cut your own remote session, so keep console access for those. This covers Oracle Solaris 11.4; SMF concepts here also apply to illumos-based systems, which share the same service-management framework.