Introducción a SMF (Service Management Facility) en Solaris

Introducción

SMF (Service Management Facility) es el sistema de gestión de servicios introducido en Solaris 10 (2005) para reemplazar el antiguo modelo basado en scripts init.d y niveles de ejecución rc. Fue diseñado desde cero para solucionar los problemas inherentes a ese modelo: arranque secuencial, falta de trazabilidad y recuperación manual ante fallos.

SMF representa un cambio de paradigma: en lugar de scripts de shell que se ejecutan en orden numérico, los servicios se definen como objetos con dependencias declarativas, estados bien definidos y capacidad de reinicio automático. El demonio svc.startd actúa como orquestador, resolviendo el grafo de dependencias e iniciando los servicios en paralelo siempre que sea posible.

Entre los beneficios más destacados de SMF se encuentran:

Ordenación por dependencias: los servicios declaran qué otros servicios necesitan antes de arrancar; SMF calcula el orden correcto automáticamente.
Arranque paralelo: los servicios sin dependencias mutuas se inician de forma concurrente, reduciendo el tiempo de boot.
Reinicio automático: si un servicio falla, SMF lo reinicia según la política configurada (restart_on). Si supera el umbral de fallos, lo pone en estado maintenance y alerta al administrador.
Delegación de privilegios: es posible autorizar a usuarios no root para administrar servicios específicos sin concederles privilegios globales.
Integración con el Fault Manager (FMA): SMF puede recibir eventos del subsistema de gestión de fallos de Solaris y reaccionar ante hardware degradado.
Trazabilidad: cada servicio tiene su propio fichero de log y un registro de transiciones de estado.

Es importante destacar que SMF es una tecnología exclusiva de Oracle Solaris (a partir de Solaris 10) y de las distribuciones basadas en illumos, el fork open source del kernel de OpenSolaris: OmniOS, SmartOS y OpenIndiana. No está disponible en Linux ni en otros sistemas Unix, aunque systemd comparte algunos conceptos similares.

Conceptos fundamentales de SMF

FMRI (Fault Management Resource Identifier)

Todo recurso gestionado por SMF se identifica mediante un FMRI. Es similar a una URI y permite referenciar unívocamente cualquier servicio o instancia. El esquema utilizado es svc: para servicios gestionados por SMF, o lrc: para servicios de compatibilidad con el antiguo modelo rc.

La estructura de un FMRI es:

text

svc://:

Ejemplos representativos:

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

Una misma definición de servicio puede tener múltiples instancias. Por ejemplo, el servicio svc:/network/smtp podría tener instancias :sendmail y :postfix. La instancia :default es la convención para servicios con una única instancia activa.

Estados de un servicio

Cada instancia de servicio se encuentra en uno de los siguientes estados en todo momento:

Estado	Descripción
`online`	El servicio está en ejecución y operativo. Es el estado objetivo normal.
`offline`	El servicio está habilitado pero sus dependencias no están satisfechas todavía, o está esperando para arrancar.
`disabled`	El servicio está administrativamente deshabilitado. No arrancará automáticamente.
`maintenance`	El servicio ha fallado repetidamente o ha sido marcado manualmente. Requiere intervención del administrador.
`degraded`	El servicio está activo pero no al 100 % de su capacidad (funcionalidad reducida).
`uninitialized`	Estado transitorio inicial; el repositorio SMF aún no ha procesado este servicio.
`legacy_run`	Servicio iniciado por el antiguo sistema `rc`; SMF lo monitoriza pero no lo gestiona completamente.

Milestones

Los milestones son servicios especiales que agrupan un conjunto de dependencias y representan un estado del sistema equivalente a los antiguos runlevels. Los principales son:

none — ningún servicio activo (equivalente a runlevel S / modo single-user mínimo).
single-user — modo monousuario, sólo servicios esenciales del sistema.
multi-user — modo multiusuario sin servicios de red completos (equivalente a runlevel 2).
multi-user-server — modo servidor completo con red (equivalente a runlevel 3). Es el milestone por defecto al arrancar.
all — todos los servicios habilitados.

El restarter: svc.startd

svc.startd es el demonio maestro de SMF. Es el primer proceso en espacio de usuario que lanza el kernel (como PID 1 en sistemas modernos Solaris) y se encarga de gestionar el ciclo de vida de todos los servicios. Existen también restarters delegados (como inetd para servicios de red bajo demanda), que pueden gestionar subconjuntos de servicios.

Comandos principales: svcs

El comando svcs es la herramienta de consulta del estado de los servicios SMF. Es de sólo lectura: no modifica nada, sólo informa.

Listar servicios

bash

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

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

La salida típica tiene tres columnas: estado, tiempo de transición al estado actual y 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

Diagnosticar servicios en mantenimiento

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

Ejemplo de salida de 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.

Ver dependencias de un servicio

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

Ver dependientes (dependencias inversas)

bash

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

Ver procesos asociados a un servicio

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

Información detallada de un servicio

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)

Gestión de servicios con svcadm

svcadm es la herramienta de administración de servicios SMF. Permite habilitar, deshabilitar, reiniciar, refrescar y cambiar el estado de los servicios. La mayoría de las operaciones requieren privilegios de root o las autorizaciones SMF adecuadas.

Habilitar y deshabilitar servicios

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

La diferencia clave entre enable y enable -t es que el primero modifica el repositorio SMF de forma permanente, mientras que el segundo sólo es efectivo hasta el siguiente arranque.

Reiniciar y refrescar servicios

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 es especialmente útil para daemons que soportan recarga de configuración en caliente (como sshd, named o nginx). Envía una señal al proceso para que relea su fichero de configuración sin interrumpir las conexiones activas.

Gestionar el estado de mantenimiento

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

Antes de ejecutar svcadm clear, asegúrate de haber resuelto el problema que causó el estado de mantenimiento. De lo contrario, el servicio volverá a fallar y puede entrar de nuevo en maintenance.

Cambiar de 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

Configuración con svccfg

svccfg es la herramienta de configuración del repositorio SMF. Permite listar y modificar propiedades de los servicios, importar y exportar manifests, y gestionar instancias. Puede usarse de forma interactiva o no interactiva.

Listar propiedades de un servicio

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

Modificar propiedades

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

Exportar e importar 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

Modo interactivo

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 y perfiles XML

Un manifest SMF es un fichero XML que describe un servicio: sus métodos de inicio y parada, dependencias, propiedades, usuario de ejecución y política de reinicio. Los manifests del sistema se encuentran en /lib/svc/manifest/ (o /var/svc/manifest/ para servicios de terceros o personalizados).

La estructura jerárquica de directorios refleja las categorías de FMRI:

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

A continuación se muestra un manifest mínimo funcional para un daemon personalizado (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>

Importar y activar el servicio

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

El atributo enabled="true" en el elemento <instance> del manifest hace que el servicio se habilite automáticamente al importarlo. Si se establece a false, queda registrado pero deshabilitado hasta que el administrador lo active explícitamente.

Logs y troubleshooting

SMF mantiene un fichero de log independiente por cada instancia de servicio. Todos los logs se almacenan en /var/svc/log/ y siguen la convención de nomenclatura:

text

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

Ejemplos:

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/

Procedimiento de diagnóstico paso a paso

Cuando un servicio entra en estado maintenance, el proceso recomendado es:

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

Problemas comunes y sus causas

Dependencias no satisfechas: el servicio espera en estado offline a que otra dependencia esté online. Usa svcs -d para identificarla.
Binario no encontrado o ruta incorrecta: el método start referencia un ejecutable inexistente. El log mostrará algo como Exec format error o No such file or directory.
Permisos insuficientes: el daemon intenta acceder a ficheros sin los permisos adecuados. Revisa method_credential en el manifest.
Fichero de configuración inválido: el daemon no puede parsear su configuración y sale con código de error no nulo. El log del servicio detallará el error específico.
Umbral de reinicios superado: SMF coloca un servicio en maintenance si falla más de un cierto número de veces en un intervalo corto. Revisa el log y el historial con svcs -xv.

Ejemplos prácticos

Habilitar y verificar 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 "

Crear un servicio personalizado desde cero

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

Diagnosticar y recuperar un servicio en mantenimiento

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

Listar todos los servicios que dependen de la red

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

Diferencias entre SMF e init.d

Para comprender mejor la ventaja de SMF, es útil compararlo con el modelo tradicional basado en scripts init.d (SysV init), que Solaris utilizó hasta la versión 9 y que todavía es el estándar en muchas distribuciones Linux que no usan systemd.

Característica	init.d / SysV	SMF (Solaris 10+)
Orden de arranque	Secuencial, controlado por prefijos numéricos (`S20foo`)	Paralelo, calculado automáticamente por el grafo de dependencias
Gestión de dependencias	Implícita (por orden numérico), sin verificación real	Declarativa y verificada; el servicio no arranca hasta que sus dependencias están online
Reinicio automático	No existe; si un servicio muere, no se reinicia salvo con herramientas externas	Nativo; política configurable por servicio (restart_on)
Logging	Redireccionado manualmente a syslog o ficheros ad-hoc en el script	Log por servicio en `/var/svc/log/`, gestionado automáticamente
Método de configuración	Scripts shell editables directamente	Propiedades tipadas en el repositorio SMF (XML + svccfg)
Separación de privilegios	Todos los scripts se ejecutan como root	Cada servicio puede definir usuario/grupo de ejecución en el manifest
Delegación administrativa	Requiere sudo o acceso root completo	Autorización granular por FMRI mediante RBAC
Diagnóstico de fallos	Sin información estructurada; hay que revisar syslog o stdout/stderr del script	Estado formalizado, log dedicado, `svcs -xv` con descripción del fallo y referencias
Transacciones en caliente	No disponible de forma nativa	`svcadm refresh` envía SIGHUP para recargar configuración sin reinicio

En resumen, SMF es una solución sustancialmente más robusta, segura y trazable para la gestión de servicios en sistemas de producción. Los entornos que requieren alta disponibilidad, auditoría de cambios y recuperación automática se benefician especialmente de las capacidades que SMF ofrece sobre el modelo SysV.

:wq!

Introducción

Conceptos fundamentales de SMF

FMRI (Fault Management Resource Identifier)

Estados de un servicio

Milestones

El restarter: svc.startd

Comandos principales: svcs

Listar servicios

Diagnosticar servicios en mantenimiento

Ver dependencias de un servicio

Ver dependientes (dependencias inversas)

Ver procesos asociados a un servicio

Información detallada de un servicio

Gestión de servicios con svcadm

Habilitar y deshabilitar servicios

Reiniciar y refrescar servicios

Gestionar el estado de mantenimiento

Cambiar de milestone

Configuración con svccfg

Listar propiedades de un servicio

Modificar propiedades

Exportar e importar manifests

Modo interactivo

Manifests y perfiles XML

Estructura básica de un manifest

Importar y activar el servicio

Logs y troubleshooting

Procedimiento de diagnóstico paso a paso

Problemas comunes y sus causas

Ejemplos prácticos

Habilitar y verificar SSH

Crear un servicio personalizado desde cero

Diagnosticar y recuperar un servicio en mantenimiento

Listar todos los servicios que dependen de la red

Diferencias entre SMF e init.d

Articulos relacionados

Hardening básico en GNU/Linux

Gestión de Versiones de Terraform con tfenv

Instalación y Configuración de BareOS en GNU/Linux

Comentarios