systemctl: todas las formas de listar servicios en Linux

El comando que hay que conocer: systemctl list-units --type=service

En cualquier distribución que use systemd — Ubuntu desde 15.04, Debian desde 8, RHEL y CentOS desde 7, además de Fedora, Arch y openSUSE — cada servicio es una unidad de systemd, y systemctl es la herramienta que las lista:

systemctl list-units --type=service

Por defecto muestra todas las unidades de servicio que systemd tiene en memoria: las que están activas, las que tienen trabajos en cola y las que han fallado. No muestra los servicios instalados que nunca se han iniciado. Cuando la salida es más larga que tu terminal, systemctl la envía a un paginador (less): pulsa q para salir, o añade --no-pager para escribir directamente en stdout.

Cada línea tiene cinco columnas:

• UNIT — el nombre de la unidad, por ejemplo ssh.service. Es el nombre exacto que pasas a systemctl status, start y stop.
• LOAD — indica si el archivo de unidad se ha analizado correctamente: loaded, not-found, bad-setting, error o masked.
• ACTIVE — el estado de alto nivel: active, inactive, activating, deactivating o failed.
• SUB — el estado de bajo nivel, propio del tipo de unidad: un servicio puede estar running, exited, dead, etc.
• DESCRIPTION — el texto legible definido en el archivo de unidad.

Lee el par ACTIVE/SUB en conjunto: active (running) significa que hay un proceso vivo en este momento, mientras que active (exited) significa que un servicio de tipo oneshot se ejecutó correctamente y terminó — algo normal en tareas de configuración, no un problema que haya que arreglar.

Filtrar: en ejecución, fallidos o todo

La opción --state= filtra por cualquier valor de LOAD, ACTIVE o SUB y acepta listas separadas por comas:

# Only services with a live process
systemctl list-units --type=service --state=running

# Everything loaded, including stopped and dead services
systemctl list-units --type=service --all

# Only failures
systemctl list-units --type=service --state=failed

# Combine states
systemctl list-units --type=service --state=running,exited

systemctl --failed es un atajo integrado para el filtro de unidades fallidas y merece la pena ejecutarlo por reflejo en cualquier máquina en la que entres. Para una salida legible por máquina, --no-legend elimina la cabecera y las líneas de resumen y --plain quita los caracteres de viñeta, de modo que las columnas se mantienen estables para awk o cut. Para buscar por nombre, canaliza la salida a grep: systemctl list-units --type=service --all --no-pager | grep ssh.

Qué arranca en el inicio: systemctl list-unit-files

list-units responde a «¿qué se está ejecutando ahora?». Para responder a «¿qué arrancará en el inicio?», lista en su lugar los archivos de unidad instalados en disco:

systemctl list-unit-files --type=service
systemctl list-unit-files --type=service --state=enabled

Aquí la columna STATE describe la configuración de arranque, no el estado en ejecución:

• enabled — arranca automáticamente en el inicio (o al activarse su disparador, en los servicios activados por socket o temporizador).
• disabled — instalado, pero nada lo arranca automáticamente.
• static — no tiene sección [Install]; solo se ejecuta como dependencia de otra unidad y no se puede habilitar directamente.
• masked — enlazado simbólicamente a /dev/null; systemd se niega a arrancarlo en cualquier caso.
• generated — creado en tiempo de ejecución por un generador, normalmente a partir de un script init heredado.

Las versiones recientes de systemd muestran además una columna de preajustes (VENDOR PRESET o PRESET según la versión) con el valor predeterminado de la distribución. La trampa que hay que evitar: habilitado no significa en ejecución, y deshabilitado no significa detenido. Un servicio puede estar deshabilitado y en ejecución porque alguien lo arrancó a mano, o habilitado y muerto porque se ha caído. Cuando importa, cruza ambos listados.

Servicio por servicio: status, is-active, is-enabled

Cuando un servicio te llame la atención, mira de cerca:

systemctl status nginx
systemctl is-active nginx    # prints: active | inactive | failed
systemctl is-enabled nginx   # prints: enabled | disabled | static | masked
systemctl is-failed nginx

status muestra el panorama completo: estado ACTIVE/SUB, PID principal, tiempo en marcha, uso de memoria, el árbol de procesos del cgroup y las diez últimas líneas del journal. Cuando diez líneas no bastan, ve directamente al journal con journalctl -xeu nginx (-u filtra por unidad, -e salta al final y -x añade texto explicativo).

Los comandos is-* están pensados para scripts: imprimen una sola palabra y ajustan el código de salida en consecuencia — is-active devuelve 0 solo cuando la unidad está activa, e is-enabled devuelve un código distinto de cero para unidades deshabilitadas o enmascaradas. Añade --quiet para suprimir la salida y conservar solo el código de salida.

Todos los comandos de listado anteriores funcionan como usuario sin privilegios. Gestionar servicios de verdad — start, stop, enable, disable — requiere root, así que conviene entender cómo funcionan sudo y el cambio de usuario en Ubuntu antes de pasar de la simple lectura del estado. Ten en cuenta también que las unidades de usuario viven en un gestor aparte: systemctl --user list-units --type=service lista los servicios que se ejecutan en tu propia sesión, lo que explica por qué algunos servicios parecen «desaparecidos» del listado del sistema.

Chuleta: los listados que realmente vas a usar

Flujos de trabajo reales

1. Encontrar el servicio que falla una y otra vez

systemctl --failed
systemctl status myapp.service --no-pager -l
journalctl -xeu myapp.service
systemctl reset-failed myapp.service

Empieza en amplio con --failed, luego lee la salida de status para ver el código de salida y las últimas líneas de log, y después profundiza en el journal para obtener la traza completa. Cuando la causa raíz esté resuelta y el servicio vuelva a estar en marcha, reset-failed borra la entrada de fallo obsoleta para que tu siguiente comprobación de salud parta limpia.

2. Auditar qué arrancará en el próximo inicio

systemctl list-unit-files --type=service --state=enabled --no-legend | awk '{print $1}'
systemd-analyze blame

El primer comando te da una lista limpia de todo lo que arrancará automáticamente — útil antes de endurecer un servidor o para rastrear algo que instalaste hace meses y olvidaste. Después, systemd-analyze blame muestra cuánto tardó cada unidad durante el último arranque, que es donde los servicios lentos destacan de inmediato.

3. Comandos de una línea para scripts y monitorización

systemctl is-active --quiet nginx && echo up || echo down
systemctl list-units --type=service --state=running --no-legend --plain | awk '{print $1}'
systemctl show -p ActiveState,SubState nginx
systemctl list-units --type=service -o json   # systemd 246 or newer

show -p imprime pares Key=Value cuyo formato nunca cambia entre versiones, y la salida JSON se puede pasar directamente a jq. Si te ves repitiendo las mismas comprobaciones cada vez que inicias sesión, envuélvelas en un pequeño script — nuestra guía sobre los archivos .sh y el scripting de shell explica cómo convertir exactamente este tipo de fragmento en una herramienta reutilizable.

¿Sin systemd? service --status-all y OpenRC

Antes de dar por hecho que systemctl existe, confirma qué ejecuta realmente la máquina — comprobar el sistema operativo y su versión desde la línea de comandos lleva diez segundos y te dice si estás en una distribución con systemd. Si falta systemctl, estás en SysV init o en OpenRC:

service --status-all

En Debian y Ubuntu esto recorre /etc/init.d e imprime [ + ] para los servicios en ejecución, [ - ] para los detenidos y [ ? ] para los scripts sin comando de estado. Sigue funcionando en distribuciones con systemd mediante una capa de compatibilidad, pero solo ve los scripts init, así que allí es mejor usar systemctl. En Alpine y Gentoo el sistema de init es OpenRC: rc-status lista los servicios del runlevel actual y rc-update show muestra qué arranca cada runlevel.

Todo lo anterior da por supuesto que tienes una máquina Linux donde eres root y puedes arrancar, romper y reparar servicios con libertad. Si necesitas una para practicar — o un servidor limpio para alojar cargas de trabajo reales — un VPS Linux con acceso root completo de rdp.monster incluye CPU y RAM dedicados, ancho de banda ilimitado (fair-use), sin KYC, y se entrega unos 10 segundos después de la confirmación del pago, así que puedes estar ejecutando systemctl list-units en tu propio servidor en menos de un minuto.

Preguntas frecuentes

¿Por qué un servicio aparece como active (exited) en lugar de active (running)?

Es un servicio oneshot que se ejecutó correctamente y terminó: no es un error.

Los servicios con Type=oneshot (o RemainAfterExit=yes) ejecutan una tarea una sola vez — montar un volumen, configurar el firewall, limpiar — y terminan. systemd informa entonces de active (exited): la unidad tuvo éxito y se considera «activa», pero no queda ningún proceso detrás. Solo los demonios como nginx o sshd muestran active (running). Si un servicio que esperas que sea un demonio aparece como exited, revisa su archivo de unidad con systemctl cat name.service para ver cómo está declarado.

¿Qué significan los puntos de color en la salida de systemctl?

Verde significa activo, blanco inactivo y rojo fallido o con error.

La viñeta que precede al nombre de una unidad en systemctl status y systemctl list-units es un indicador rápido de estado: verde para activo, blanco para inactivo o desactivándose y rojo para estados fallidos o de error. Las filas fallidas también se resaltan en rojo en los listados, lo que hace fácil revisar systemctl --failed de un vistazo. En scripts o logs donde los códigos de color molestan, añade --plain o canaliza la salida y las decoraciones desaparecen.

¿Existe un equivalente de chkconfig --list en systemctl?

Sí: systemctl list-unit-files --type=service sustituye a chkconfig --list.

En RHEL y CentOS 7 o posteriores, chkconfig --list se sustituye por systemctl list-unit-files --type=service, que muestra todos los servicios instalados y si están enabled, disabled, static o masked. Para un solo servicio, systemctl is-enabled name sustituye a chkconfig name, y systemctl enable name a chkconfig name on. El comando antiguo puede seguir existiendo como capa de compatibilidad, pero solo cubre los scripts SysV heredados.

¿Cómo evito que un servicio arranque en el inicio?

Usa systemctl disable para quitarlo del arranque, o mask para bloquearlo por completo.

Ejecuta sudo systemctl disable name para eliminar el enlace simbólico de arranque; añade --now para detenerlo también de inmediato. Un servicio deshabilitado todavía puede arrancarse a mano o ser arrastrado como dependencia de otra unidad. Si quieres que no arranque nunca, usa sudo systemctl mask name, que enlaza la unidad a /dev/null para que todo intento de arranque falle. Puedes revertirlo después con systemctl unmask. Comprueba el resultado con systemctl is-enabled name.