Introduction to SMF (Service Management Facility) on Solaris

SMF (Service Management Facility) is the service management system introduced in Solaris 10 (2005) to replace the old init.d script-based model. ===

Introduction

SMF (Service Management Facility) is the service management system introduced in Solaris 10 (2005) to replace the old script-based model init.d and execution levels rc. It was designed from the ground up to solve the problems inherent to that model: sequential startup, lack of traceability and manual recovery from failures.

SMF represents a paradigm shift: instead of shell scripts that are executed in numerical order, services are defined as objects with declarative dependencies, well-defined states and automatic restart capability. the demon svc.startd acts as an orchestrator, resolving the dependency graph and starting services in parallel whenever possible.

Among the most notable benefits of SMF are:

Sorting by dependencies: services declare what other services they need before starting; SMF calculates the correct order automatically.
Parallel start: Services without mutual dependencies are started concurrently, reducing boot time.
Auto restart: If a service fails, SMF restarts it based on the configured policy (restart_on). If it exceeds the failure threshold, it puts it in state maintenance and alert the administrator.
Delegation of privileges: It is possible to authorize non-root users to manage specific services without granting them global privileges.
Integration with Fault Manager (FMA): SMF can receive events from the Solaris fault management subsystem and react to degraded hardware.
Traceability: Each service has its own log file and a record of state transitions.

It is important to highlight that SMF is a technology Oracle Solaris exclusive (as of Solaris 10) and distributions based on illumos, the open source fork of the OpenSolaris kernel: OmniOS, SmartOS and OpenIndiana. It is not available on Linux or other Unix systems, although systemd shares some similar concepts.

SMF Fundamentals

FMRI (Fault Management Resource Identifier)

Every resource managed by SMF is identified by a FMRI. It is similar to a URI and allows any service or instance to be uniquely referenced. The scheme used is svc: for services managed by SMF, or lrc: for backward compatibility services rc.

The structure of an FMRI is:

text

svc://:

Representative examples:

text

svc:/network/ssh:default
svc:/system/cron:default
svc:/network/nfs/server:default
svc:/milestone/multi-user:default
lrc:/etc/rc2_d/S99my_legacy_service

The same service definition can have multiple instances. For example, the service svc:/network/smtp could have instances :sendmail and :postfix. The instance :default is the convention for services with a single active instance.

States of a service

Each service instance is in one of the following states at all times:

State	Description
`online`	The service is running and operational. It is the normal objective state.
`offline`	The service is enabled but its dependencies are not satisfied yet, or it is waiting to start.
`disabled`	The service is administratively disabled. It will not start automatically.
`maintenance`	The service has failed repeatedly or has been dialed manually. Requires administrator intervention.
`degraded`	The service is active but not at 100% capacity (reduced functionality).
`uninitialized`	Initial transient state; the SMF repository has not yet processed this service.
`legacy_run`	Service started by the old system `rc`; SMF monitors it but does not fully manage it.

Milestones

The milestones are special services that group a set of dependencies and represent a system state equivalent to the old ones runlevels. The main ones are:

none — no active service (equivalent to runlevel S / minimum single-user mode).
single-user — single-user mode, only essential system services.
multi-user — multi-user mode without full network services (equivalent to runlevel 2).
multi-user-server — full server mode with network (equivalent to runlevel 3). It is the default milestone at startup.
there — all services enabled.

The restarter: svc.startd

svc.startd is the master daemon of SMF. It is the first process in user space that launches the kernel (as PID 1 on modern Solaris systems) and is responsible for managing the lifecycle of all services. There are also delegated restarters (as inetd for on-demand network services), which can manage subsets of services.

Main commands: svcs

The command svcs It is the tool for consulting the status of SMF services. It is read-only: it does not modify anything, it only informs.

List services

Bash

# Listar todos los servicios online (estado por defecto)
svcs

# Listar TODOS los servicios, incluidos los deshabilitados
svcs -a

The typical output has three columns: status, transition time to current state, and FMRI:

text

STATE          STIME    FMRI
legacy_run     Apr_17   lrc:/etc/rc2_d/S47pppd
online         Apr_17   svc:/system/early-manifest-import:default
online         Apr_17   svc:/system/svc/restarter:default
online         Apr_17   svc:/network/loopback:default
online         Apr_17   svc:/network/ssh:default
disabled       Apr_17   svc:/network/ftp:default

Diagnose maintenance services

Bash

# Mostrar explicación de todos los servicios con problemas
svcs -x

# Mostrar explicación detallada de un servicio concreto
svcs -x svc:/network/ftp:default

Example of output svcs -x svc:/network/ftp:default:

text

svc:/network/ftp:default (FTP server)
 State: maintenance since Sun Apr 17 22:14:05 2026
Reason: Start method failed repeatedly, last exited with status 1.
   See: http://sun.com/msg/SMF-8000-KS
   See: /var/svc/log/network-ftp:default.log
Impact: This service is not running.

View dependencies of a service

Bash

# Mostrar dependencias (lo que necesita este servicio)
svcs -d svc:/system/dumpadm:default

text

STATE          STIME    FMRI
online         Apr_17   svc:/system/filesystem/local:default
online         Apr_17   svc:/system/identity:node

View dependents (inverse dependencies)

Bash

# Mostrar qué servicios dependen de este (dependientes)
svcs -D svc:/network/loopback:default

View processes associated with a service

Bash

# Listar los PIDs de los procesos del servicio
svcs -p svc:/network/ssh:default

text

STATE          STIME    FMRI
online         Apr_17   svc:/network/ssh:default
               Apr_17      1023 sshd

Detailed information about a service

Bash

# Listado largo con todas las propiedades del servicio
svcs -l svc:/network/ssh:default

text

fmri         svc:/network/ssh:default
name         SSH server
enabled      true
state        online
next_state   none
state_time   Sun Apr 17 10:22:33 2026
logfile      /var/svc/log/network-ssh:default.log
restarter    svc:/system/svc/restarter:default
contract_id  128
dependency   require_all/error svc:/network/loopback:default (online)
dependency   require_all/none  svc:/system/cryptosvc:default (online)

Service management with svcadm

svcadm is the SMF service management tool. Allows you to enable, disable, restart, refresh and change the status of services. Most operations require root privileges or the appropriate SMF authorizations.

Enable and disable services

Bash

# Habilitar un servicio de forma persistente (survives reboot)
svcadm enable svc:/network/ssh:default

# Habilitar de forma temporal (sólo hasta el próximo reinicio)
svcadm enable -t svc:/network/ftp:default

# Deshabilitar un servicio (persistente)
svcadm disable svc:/network/ftp:default

# Deshabilitar de forma temporal
svcadm disable -t svc:/network/ftp:default

The key difference between enable and enable -t is that the first modifies the SMF repository permanently, while the second is only effective until the next boot.

Restart and refresh services

Bash

# Reiniciar un servicio (stop + start)
svcadm restart svc:/network/ssh:default

# Refrescar la configuración sin detener el servicio (equivale a SIGHUP)
svcadm refresh svc:/network/ssh:default

refresh is especially useful for daemons that support hot configuration reloading (such as sshd, named either nginx). Sends a signal to the process to reread its configuration file without interrupting active connections.

Manage maintenance status

Bash

# Limpiar el estado de mantenimiento tras corregir el problema
svcadm clear svc:/network/ftp:default

# Poner manualmente un servicio en estado de mantenimiento
svcadm mark maintenance svc:/network/ftp:default

# Poner en mantenimiento de forma temporal
svcadm mark -t maintenance svc:/network/ftp:default

Before running svcadm clear, make sure you have resolved the issue that caused the maintenance status. Otherwise, the service will fail again and may enter again. maintenance.

Change milestone

Bash

# Cambiar al milestone single-user (equivale a init S)
svcadm milestone single-user

# Volver al milestone multi-user-server (equivale a init 3)
svcadm milestone multi-user-server

# Ir al milestone "none" (detener casi todos los servicios)
svcadm milestone none

Configuration with svccfg

svccfg is the SMF repository configuration tool. It allows you to list and modify service properties, import and export manifests, and manage instances. It can be used interactively or non-interactively.

List properties of a service

Bash

# Listar todos los grupos de propiedades e instancias
svccfg -s svc:/network/ssh:default listprop

# Listar sólo un grupo concreto de propiedades
svccfg -s svc:/network/ssh:default listprop config

Modify properties

Bash

# Establecer el valor de una propiedad (tipo astring)
svccfg -s svc:/network/ssh:default setprop config/listen_addr = astring: "0.0.0.0"

# Tras modificar propiedades, refrescar para que el servicio las aplique
svcadm refresh svc:/network/ssh:default

Export and import manifests

Bash

# Exportar el manifest actual de un servicio a XML
svccfg export svc:/network/ssh:default > /tmp/ssh-manifest.xml

# Importar un manifest XML al repositorio SMF
svccfg import /tmp/mi-servicio.xml

# Validar un manifest sin importarlo
svccfg validate /tmp/mi-servicio.xml

Interactive mode

Bash

# Entrar en modo interactivo
svccfg

# Dentro del prompt svccfg>:
svccfg> select svc:/network/ssh:default
svccfg> listprop
svccfg> setprop general/enabled = true
svccfg> quit

Manifests and XML profiles

A manifest SMF is an XML file that describes a service: its start and stop methods, dependencies, properties, execution user and restart policy. The system manifests are located at /lib/svc/manifest/ (either /var/svc/manifest/ for third-party or personalized services).

The hierarchical directory structure reflects the FMRI categories:

text

/lib/svc/manifest/
├── network/
│   ├── ssh.xml
│   ├── ftp.xml
│   └── nfs/
├── system/
│   ├── cron.xml
│   └── syslog.xml
└── site/           ← servicios personalizados del sitio

Estructura básica de un manifest

Below is a minimal functional manifest for a custom daemon (midaemon):

xml

<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">

<service_bundle type="manifest" name="midaemon">

  <service
    name="site/midaemon"
    type="service"
    version="1">

    <!-- Instancia por defecto, habilitada al importar -->
    <instance name="default" enabled="true">

      <!-- Dependencias: necesita que el sistema de ficheros local esté montado -->
      <dependency
        name="fs-local"
        grouping="require_all"
        restart_on="none"
        type="service">
        <service_fmri value="svc:/system/filesystem/local:default"/>
      </dependency>

      <!-- Dependencia de red -->
      <dependency
        name="network"
        grouping="require_all"
        restart_on="error"
        type="service">
        <service_fmri value="svc:/milestone/network:default"/>
      </dependency>

      <!-- Método de inicio -->
      <exec_method
        type="method"
        name="start"
        exec="/opt/midaemon/bin/midaemon -D"
        timeout_seconds="60">
        <method_context>
          <method_credential user="root" group="root"/>
        </method_context>
      </exec_method>

      <!-- Método de parada -->
      <exec_method
        type="method"
        name="stop"
        exec=":kill"
        timeout_seconds="30"/>

      <!-- Política de reinicio -->
      <property_group name="startd" type="framework">
        <propval name="duration" type="astring" value="contract"/>
        <propval name="ignore_error" type="astring" value="core,signal"/>
      </property_group>

    </instance>

    <!-- Metadatos del servicio -->
    <stability value="Unstable"/>

    <template>
      <common_name>
        <loctext xml:lang="C">Mi daemon personalizado</loctext>
      </common_name>
      <description>
        <loctext xml:lang="C">Daemon de ejemplo para ilustrar manifests SMF.</loctext>
      </description>
    </template>

  </service>

</service_bundle>

Import and activate the service

Bash

# 1. Validar el manifest antes de importar
svccfg validate /var/svc/manifest/site/midaemon.xml

# 2. Importar el manifest al repositorio SMF
svccfg import /var/svc/manifest/site/midaemon.xml

# 3. Verificar que el servicio fue registrado
svcs svc:/site/midaemon:default

# 4. Si no se habilitó automáticamente, habilitarlo
svcadm enable svc:/site/midaemon:default

The attribute enabled="true" in the element <instance> del manifest causes the service to be enabled automatically when imported. If set to false, it is registered but disabled until the administrator explicitly activates it.

Logs and troubleshooting

SMF maintains a separate log file for each service instance. All logs are stored in /var/svc/log/ and follow the naming convention:

text

<categoría>-<nombre-servicio>:<instancia>.log

Examples:

Bash

# Log del servicio SSH
cat /var/svc/log/network-ssh:default.log

# Log del servicio FTP
cat /var/svc/log/network-ftp:default.log

# Log de svc.startd (el restarter global)
cat /var/svc/log/system-svc-restarter:default.log

# Listar todos los logs disponibles
ls /var/svc/log/

Step-by-step diagnostic procedure

When a service enters state maintenance, the recommended process is:

Bash

# Paso 1: identificar servicios en estado de mantenimiento
svcs -a | grep maintenance

# Paso 2: obtener explicación detallada del fallo
svcs -xv svc:/network/ftp:default

# Paso 3: revisar el log del servicio para ver el error concreto
cat /var/svc/log/network-ftp:default.log

# Paso 4: verificar las dependencias del servicio
svcs -d svc:/network/ftp:default

# Paso 5: corregir el problema (editar config, instalar binario, etc.)

# Paso 6: limpiar el estado de mantenimiento para reintentar el arranque
svcadm clear svc:/network/ftp:default

# Paso 7: verificar que vuelve a estado online
svcs svc:/network/ftp:default

Common problems and their causes

Unsatisfied dependencies: the service waits in status offline to which other dependency is on-line. Use svcs -d to identify it.
Binary not found or wrong path: the method start references a non-existent executable. The log will show something like Exec format error either No such file or directory.
Insufficient permissions: The daemon tries to access files without the appropriate permissions. Review method_credential in the manifesto
Invalid configuration file: The daemon cannot parse its configuration and exits with a non-null error code. The service log will detail the specific error.
Reboot threshold exceeded: SMF places a service on maintenance if it fails more than a certain number of times in a short interval. Review the log and history with svcs -xv.

Practical examples

Enable and verify SSH

Bash

# Habilitar SSH de forma persistente
svcadm enable svc:/network/ssh:default

# Verificar que está online
svcs svc:/network/ssh:default

# Ver el proceso sshd asociado
svcs -p svc:/network/ssh:default

# Confirmar que el puerto 22 está a la escucha
netstat -an | grep ".22 "

Create a personalized service from scratch

Bash

# 1. Crear el manifest (ver sección de Manifests XML)
vi /var/svc/manifest/site/midaemon.xml

# 2. Validar la sintaxis XML
svccfg validate /var/svc/manifest/site/midaemon.xml

# 3. Importar al repositorio SMF
svccfg import /var/svc/manifest/site/midaemon.xml

# 4. Verificar registro e inicio
svcs svc:/site/midaemon:default

# 5. Consultar el log si hay problemas
cat /var/svc/log/site-midaemon:default.log

Diagnose and recover a service under maintenance

Bash

# Imagina que svc:/network/ftp:default está en maintenance

# 1. Ver descripción del problema
svcs -x svc:/network/ftp:default
# Salida: "Start method failed repeatedly, last exited with status 1"

# 2. Ver el log del servicio
tail -50 /var/svc/log/network-ftp:default.log
# Salida: "500 OOPS: cannot change directory:/home/ftp"

# 3. Corregir el problema (directorio ftp home no existía)
mkdir -p /home/ftp
chown root:root /home/ftp
chmod 555 /home/ftp

# 4. Limpiar el estado de mantenimiento
svcadm clear svc:/network/ftp:default

# 5. Verificar recuperación
svcs svc:/network/ftp:default
# Esperado: online

List all services that depend on the network

Bash

# Ver qué servicios dependen del milestone de red
svcs -D svc:/milestone/network:default

# Ver qué servicios dependen del loopback
svcs -D svc:/network/loopback:default

Differences between SMF and init.d

To better understand the advantage of SMF, it is useful to compare it with the traditional script-based model init.d (SysV init), which was used by Solaris until version 9 and is still the standard on many Linux distributions that do not use systemd.

Feature	init.d/SysV	SMF (Solaris 10+)
Boot order	Sequential, controlled by numerical prefixes (`S20foo`)	Parallel, automatically calculated by the dependency graph
Dependency management	Implicit (in numerical order), without actual verification	Declarative and verified; the service does not start until its dependencies are online
Automatic restart	It does not exist; If a service dies, it is not restarted except with external tools	Native; policy configurable per service (restart_on)
Logging	Manually redirected to syslog or ad-hoc files in the script	Log for service in `/var/svc/log/`, managed automatically
Setting method	Directly editable shell scripts	Typed properties in SMF repository (XML + svccfg)
Separation of privileges	All scripts run as root	Each service can define user/execution group in the manifest
Administrative delegation	Requires sudo or full root access	Granular authorization by FMRI using RBAC
Fault diagnosis	No structured information; you have to check syslog or stdout/stderr of the script	Formalized status, dedicated log, `svcs -xv` with description of the fault and references
Hot transactions	Not available natively	`svcadm refresh` send SIGHUP to reload configuration without reboot

In summary, SMF is a substantially more robust, secure and traceable solution for service management in production systems. Environments that require high availability, change auditing, and automatic recovery especially benefit from the capabilities that SMF offers over the SysV model.

:wq!

Introduction

SMF Fundamentals

FMRI (Fault Management Resource Identifier)

States of a service

Milestones

The restarter: svc.startd

Main commands: svcs

List services

Diagnose maintenance services

View dependencies of a service

View dependents (inverse dependencies)

View processes associated with a service

Detailed information about a service

Service management with svcadm

Enable and disable services

Restart and refresh services

Manage maintenance status

Change milestone

Configuration with svccfg

List properties of a service

Modify properties

Export and import manifests

Interactive mode

Manifests and XML profiles

Estructura básica de un manifest

Import and activate the service

Logs and troubleshooting

Step-by-step diagnostic procedure

Common problems and their causes

Practical examples

Enable and verify SSH

Create a personalized service from scratch

Diagnose and recover a service under maintenance

List all services that depend on the network

Differences between SMF and init.d

Related articles

Basic hardening in GNU/Linux

Comments