Tutorial completo del comando systemctl en Linux

Dominar systemctl y systemd es casi obligatorio hoy en día si administras servidores o equipos Linux modernos. Esta herramienta es la puerta de entrada para controlar qué servicios se inician, cómo lo hacen, qué ha fallado y en qué estado real se encuentra tu sistema en cada momento. Una vez que le pillas el truco, te ahorras muchos quebraderos de cabeza y bastantes reinicios innecesarios.

A lo largo de esta guía vas a ver de forma ordenada y con ejemplos cómo usar systemctl para gestionar servicios, unidades y objetivos, cómo listar lo que está pasando en el sistema, cómo editar unidades sin romper nada, qué significan estados como enabled, masked o static, y también trucos para apagar, reiniciar o cambiar de modo gráfico a modo texto con un solo comando. Todo ello usando un español de España, directo y práctico, pensado para que puedas aplicar lo que leas en cualquier distro basada en systemd (Ubuntu, Debian, RHEL, CentOS, Fedora, Arch, etc.).

Qué es systemd y qué papel juega systemctl

En la mayoría de distribuciones actuales, systemd actúa como sistema de inicio e infraestructura base. Es el proceso que arranca justo después del kernel (normalmente como PID 1) y el que se encarga de levantar el resto de servicios, montar sistemas de archivos, gestionar dependencias, controlar sesiones, registrar eventos y un largo etcétera.

systemd está formado por demonios, bibliotecas y utilidades que permiten hablar con el núcleo y con el espacio de usuario: gestiona grupos de control (cgroups), sockets, temporizadores, puntos de montaje, configuración de red básica, sincronización horaria, resolución de nombres, contenedores y máquinas virtuales, e incluso es compatible con scripts antiguos de SysV y LSB, por lo que puede sustituir completamente a sysvinit clásico.

Dentro de todo este ecosistema, systemctl es el “mando a distancia” de systemd. Es la utilidad de línea de comandos que utilizas para:

• Iniciar, parar, reiniciar o recargar servicios y otros tipos de unidades.
• Habilitar o deshabilitar unidades para que arranquen (o no) con el sistema.
• Consultar el estado de servicios, objetivos y del sistema en general.
• Editar archivos de unidad o ver sus dependencias y propiedades internas.
• Cambiar el estado global del sistema (modo rescate, multiusuario, gráfico, apagado, reinicio…).

Ten en cuenta que no todas las distribuciones usan systemd. Si al ejecutar systemctl ves un mensaje del estilo bash: systemctl: command not found o algo similar, es probable que tu sistema use otro init (OpenRC, runit, SysV puro, etc.). En ese caso, los comandos de esta guía no aplican tal cual.

Unidades y archivos de unidad en systemd

El concepto clave en systemd son las unidades (units). Una unidad representa cualquier recurso que systemd es capaz de gestionar: un servicio, un socket, un punto de montaje, un dispositivo, un objetivo global del sistema, un temporizador… Cada tipo de unidad se identifica por un sufijo en el nombre del archivo.

Algunos tipos de unidades más habituales que verás al trabajar con systemctl y systemd son:

• .service: servicios y demonios (nginx.service, ssh.service, NetworkManager.service…).
• .socket: sockets asociados a servicios arrancados bajo demanda.
• .mount: puntos de montaje de sistemas de archivos.
• .automount: montajes automáticos activados al uso.
• .target: “estados” del sistema (multi-user.target, graphical.target, rescue.target…).
• .timer: temporizadores que lanzan servicios en momentos concretos.
• .device: dispositivos gestionados por udev.
• .path: vigilantes de rutas en disco que disparan servicios.

Cada unidad se define en un archivo de unidad (unit file), que es un fichero de texto con secciones como , , , donde se detallan la descripción, dependencias, comandos de arranque, usuario que ejecuta el servicio, etc. Estos archivos se almacenan normalmente en:

• /lib/systemd/system/ o /usr/lib/systemd/system/: unidades que vienen con los paquetes.
• /etc/systemd/system/: unidades definidas o sobreescritas por el administrador.

Cuando trabajas con systemctl, casi siempre te refieres a unidades de tipo .service, aunque si omites el sufijo, systemd asume por defecto que hablas de un servicio. Es decir, systemctl start ssh y systemctl start ssh.service son equivalentes.

Hay unidades especiales llamadas plantillas, cuyo nombre incluye @, por ejemplo name@.service. Al instanciar una plantilla como name@miinstancia.service, lo que haces es crear una instancia concreta pasando un identificador; dentro del archivo de unidad, la variable %i se sustituye por ese identificador. Esto se usa mucho en túneles SSH, servicios por interfaz de red, etc.

Comprobar si tu sistema usa systemd

Antes de volverte loco con los comandos, conviene comprobar si tu distro realmente está usando systemd como PID 1. En muchas guías se sugiere algo tan simple como:

pstree | head -5

Si en la parte superior del árbol ves un proceso systemd, puedes seguir adelante sin problema. Si ves otro init, deberás usar las herramientas específicas de ese sistema de inicio.

Gestión básica de servicios con systemctl

La operación del día a día con systemd suele centrarse en iniciar, parar, reiniciar y recargar servicios. Estos comandos afectan al estado actual del servicio, no a si se arrancará o no automáticamente con el sistema.

Para comprobar el estado de un servicio, puedes usar:

systemctl status nombre_servicio.service

Por ejemplo, para ver cómo está el servicio de red systemd-networkd en una Ubuntu en modo texto:

systemctl status systemd-networkd.service

Este comando muestra información bastante detallada: estado (active, inactive, failed…), cuándo se activó, el PID principal, uso de CPU, y unos cuantos mensajes de log recientes que vienen muy bien para diagnosticar problemas.

Si quieres algo más directo, puedes usar estas variantes específicas:

• systemctl is-active nombre.service: indica si está activo (running) o no.
• systemctl is-enabled nombre.service: indica si se arrancará al inicio.
• systemctl is-failed nombre.service: comprueba si entró en estado de fallo.

Por ejemplo, para ver si systemd-networkd está habilitado al arranque puedes ejecutar:

systemctl is-enabled systemd-networkd.service

Y para saber si falló al arrancar en algún momento:

systemctl is-failed systemd-networkd.service

Arrancar, parar, reiniciar y recargar servicios

Para detener un servicio que esté funcionando, la orden típica es:

sudo systemctl stop nombre_servicio.service

Ten en cuenta que al tratarse de una acción que afecta al sistema, necesitarás privilegios de administración, normalmente usando sudo. En algunos servicios “tozudos”, como systemd-networkd, al pararlos volverán a levantarse inmediatamente si hay alguna unidad que los requiera y tenga políticas de reinicio automáticas.

Si el servicio está parado y quieres iniciarlo, usas el mismo patrón con start:

sudo systemctl start systemd-networkd.service

Cuando has cambiado un fichero de configuración y quieres aplicar los cambios, lo más habitual es reiniciar el servicio:

sudo systemctl restart nombre_servicio.service

Muchos demonios permiten recargar su configuración sin reiniciar del todo, evitando cortar conexiones activas. En esos casos se usa:

sudo systemctl reload nombre_servicio.service

Si no tienes claro si ese servicio soporta recarga, puedes tirar de:

sudo systemctl reload-or-restart nombre_servicio.service

Con este comando, systemctl intenta recargar primero y, si la unidad no implementa recarga, procede a hacer un reinicio completo. Es muy útil cuando no recuerdas el comportamiento concreto de cada demonio.

Habilitar y deshabilitar servicios en el arranque

Todo lo que hemos visto hasta ahora afecta solo a la sesión actual. Si quieres que un servicio se encienda solo al arrancar el sistema, tienes que habilitarlo (enable). El comando básico es:

sudo systemctl enable nombre_servicio.service

Al hacerlo, systemd crea enlaces simbólicos desde el archivo de servicio del sistema (normalmente en /lib/systemd/system o /etc/systemd/system) hasta un directorio .wants correspondiente al objetivo donde debe activarse. Por ejemplo, algo como:

/etc/systemd/system/multi-user.target.wants/nombre_servicio.service

Si quieres justo lo contrario, es decir, evitar que un servicio se inicie automáticamente en el próximo arranque, lo deshabilitas:

sudo systemctl disable nombre_servicio.service

Esto elimina los enlaces simbólicos de autoarranque, pero no detiene el servicio que ya está corriendo. Del mismo modo, habilitar un servicio tampoco lo pone en marcha al instante: solo será efectivo a partir del siguiente reinicio, a menos que combines:

sudo systemctl enable nombre_servicio.service
sudo systemctl start nombre_servicio.service

Algunas distros y herramientas ofrecen atajos para habilitar e iniciar a la vez, pero la forma estándar con systemctl suele ser ejecutar ambos comandos.

Ver el estado global de las unidades

systemctl no sirve solo para tocar servicios individuales; también permite tener una panorámica del sistema. El comando más típico es:

systemctl list-units

Este listado muestra todas las unidades activas que systemd tiene presentes en memoria. Las columnas principales son:

• UNIT: nombre de la unidad (por ejemplo, sshd.service).
• LOAD: si el archivo de unidad se ha cargado correctamente (loaded, not-found, error…).
• ACTIVE: estado general (active, inactive, failed…).
• SUB: subestado más descriptivo (running, exited, dead, failed…).
• DESCRIPTION: breve descripción de la unidad.

Si llamas a systemctl sin argumentos, verás prácticamente el mismo listado, ya que ese es su comportamiento por defecto. Como solo se muestran unidades activas, casi todo aparecerá con LOAD=loaded y ACTIVE=active.

Para incluir también unidades inactivas, puedes añadir el indicador --all:

systemctl list-units --all

Además puedes filtrar por estado con --state=, por ejemplo para ver solo unidades inactivas:

systemctl list-units --all --state=inactive

O filtrar por tipo de unidad con --type=. Por ejemplo, para ver solo servicios activos:

systemctl list-units --type=service

Listar todos los archivos de unidad instalados

El listado anterior solo muestra unidades que systemd ha intentado cargar. Si quieres saber todas las unidades que existen en disco, uses o no uses, debes recurrir a:

systemctl list-unit-files

Aquí el foco está en los propios ficheros de unidad, no en su estado en memoria. Verás dos columnas principales: UNIT FILE y STATE. En STATE aparecen valores como:

• enabled: la unidad está configurada para arrancar automáticamente.
• disabled: no está configurada para el inicio automático.
• static: la unidad no tiene sección , por lo que no puede habilitarse por sí misma. Suele ser una dependencia de otras unidades o ejecutar una acción puntual.
• masked: la unidad está totalmente bloqueada, no se puede iniciar de ninguna forma.

Además puedes filtrar por estado, por ejemplo para ver solo unidades habilitadas:

systemctl list-unit-files --state=enabled

O combinar varios estados en una sola consulta separándolos por comas:

systemctl list-unit-files --state=enabled,failed

Ver detalles, propiedades y dependencias de una unidad

Si quieres ver el contenido real del archivo de unidad que systemd está usando, el comando más cómodo es:

systemctl cat nombre.service

Esto muestra el archivo tal y como lo ve systemd, incluyendo posibles fragmentos de override desde /etc/systemd/system. Es muy útil para confirmar que tus cambios han sido realmente tenidos en cuenta.

Para inspeccionar el árbol de dependencias de una unidad, puedes usar:

systemctl list-dependencies nombre.service

La salida es jerárquica, mostrando qué objetivos y servicios tiran del servicio en cuestión. Las unidades de tipo .target actúan como puntos de agrupación y solo ellas muestran recursivamente sus dependencias por defecto; si quieres expandir todo el árbol, añade --all.

Si lo que necesitas es saber qué unidades dependen de la que has indicado, añade --reverse al comando. Y si quieres centrarte en el orden de arranque, los flags --before y --after muestran unidades que deben arrancar antes o después de la unidad objetivo.

Para ver todas las propiedades internas de una unidad en formato clave=valor, usa:

systemctl show nombre.service

Y si solo te interesa una propiedad concreta, puedes filtrar con -p. Por ejemplo, para ver los conflictos de sshd:

systemctl show sshd.service -p Conflicts

Enmascarar y desenmascarar unidades

Además de deshabilitar, systemd permite enmascarar una unidad para que sea totalmente imposible arrancarla, ya sea manualmente o por dependencia de otra unidad. Esta técnica se usa cuando quieres asegurarte al 100% de que algo no se arranca ni por error.

El enmascarado se implementa creando un enlace simbólico a /dev/null en lugar del archivo de unidad real. Para enmascarar un servicio, por ejemplo nginx:

sudo systemctl mask nginx.service

Si después ejecutas systemctl list-unit-files, verás que nginx.service aparece como masked. Y si intentas arrancarlo:

sudo systemctl start nginx.service

Obtendrás un mensaje del tipo: Failed to start nginx.service: Unit nginx.service is masked. Es decir, la unidad está blindada. Para volver a dejarla utilizable hay que desenmascararla:

sudo systemctl unmask nginx.service

Tras esto, la unidad vuelve a su estado anterior (enabled, disabled, static, etc.) y ya se puede iniciar o habilitar con normalidad.

Editar archivos de unidad sin romper el sistema

A veces necesitas ajustar el comportamiento de un servicio: cambiar el usuario que lo ejecuta, añadir opciones a la línea de comandos, modificar dependencias… En lugar de editar a mano los archivos en /lib/systemd/system, lo más seguro es usar el propio systemctl para generar overrides.

El comando básico es:

sudo systemctl edit nombre.service

Esto abre tu editor por defecto con un archivo de fragmento vacío. Al guardar y salir, systemd creará un directorio en /etc/systemd/system/nombre.service.d/ y dentro un archivo override.conf. Al cargar la unidad, systemd fusiona el archivo original con este fragmento, y las directivas del override tienen prioridad sobre las del archivo base.

Si quieres editar el archivo de unidad completo en lugar de un override, puedes hacerlo con:

sudo systemctl edit --full nombre.service

En este caso, lo que guardes se escribirá en /etc/systemd/system/nombre.service, que tiene precedencia sobre la versión del sistema en /lib/systemd/system. Es una forma de “clonar” y personalizar completamente una unidad sin tocar los archivos que vienen con el paquete.

Si más adelante decides deshacer tus cambios, basta con eliminar el directorio .d del override o el archivo de servicio modificado en /etc/systemd/system. Por ejemplo:

sudo rm -r /etc/systemd/system/nginx.service.d
sudo rm /etc/systemd/system/nginx.service

Tras borrar estos elementos, es importantísimo ejecutar:

sudo systemctl daemon-reload

Así obligas a systemd a recargar todos los archivos de unidad, olvidarse de los overrides eliminados y volver a utilizar las definiciones originales de sistema.

Objetivos (targets) y adaptación del “runlevel”

Los targets de systemd son el equivalente moderno a los runlevels de SysV. Son unidades especiales (terminan en .target) que agrupan otras unidades para representar “estados” o puntos de sincronización del sistema.

Por ejemplo:

• multi-user.target: modo multiusuario en consola, típico de servidores sin entorno gráfico.
• graphical.target: modo gráfico; suele depender de multi-user.target y añade la capa de interfaz gráfica.
• rescue.target: modo rescate, similar al “single user mode”.
• swap.target: punto en el que el área de intercambio está lista para usarse.

Las unidades pueden declarar relaciones como WantedBy=, RequiredBy=, Wants=, Requires=, After= con estos objetivos para indicar de qué dependen y en qué orden deben levantarse.

Para saber cuál es el objetivo predeterminado de tu sistema (el estado al que se quiere llegar en un arranque normal), usa:

systemctl get-default

Si por ejemplo prefieres que el sistema arranque siempre en modo gráfico, puedes cambiarlo con:

sudo systemctl set-default graphical.target

Para ver todos los objetivos instalados en el sistema, con su estado (enabled, disabled…), puedes ejecutar:

systemctl list-unit-files --type=target

Y si lo que quieres es ver qué targets están activos ahora mismo, lo haces con:

systemctl list-units --type=target

Aislar objetivos y cambiar de modo de trabajo

Una de las cosas más potentes que ofrece systemd es la posibilidad de cambiar el estado del sistema “aislando” un target. Cuando ejecutas un aislamiento, systemd activa todas las unidades necesarias para ese objetivo y detiene las que ya no encajan en su árbol de dependencias.

Imagina que estás en un entorno gráfico (activo graphical.target) y quieres pasar a un entorno solo texto, multiusuario, por ejemplo para tareas de mantenimiento. Puedes revisar primero las dependencias de multi-user.target:

systemctl list-dependencies multi-user.target

Y cuando tengas claro que no te vas a cargar nada crítico, lanzas:

sudo systemctl isolate multi-user.target

Como graphical.target depende de multi-user.target pero no al revés, al aislar el objetivo multiusuario se detendrán todos los servicios asociados a la capa gráfica, dejándote en modo texto. Es un cambio bastante radical, así que conviene usarlo con cabeza.

Para eventos muy habituales, systemctl ofrece atajos cómodos frente a escribir isolate a mano. Algunos de los más usados son:

• sudo systemctl rescue: cambia al modo rescate (equivalente a aislar rescue.target) y avisa a los usuarios conectados.
• sudo systemctl halt: detiene el sistema (similar a apagar CPU sin cortar alimentación).
• sudo systemctl poweroff: apaga la máquina completamente.
• sudo systemctl reboot: reinicia el sistema.

Normalmente, comandos clásicos como reboot, poweroff o halt están enlazados internamente para hablar con systemd, de modo que se comportan de forma coherente con estos atajos.

Comandos esenciales adicionales de systemctl

Además de todo lo anterior, hay algunos comandos de systemctl que conviene tener muy a mano porque los usarás con frecuencia cuando toques unidades:

Recargar la configuración de systemd (no de los servicios):

sudo systemctl daemon-reload

Cada vez que modifiques o añadas archivos de unidad, es necesario avisar a systemd para que los vuelva a leer. Este comando no reinicia servicios, solo recarga la base de datos de unidades.

Consultar el estado de un servicio con detalles (ya comentado):

sudo systemctl status nombre_servicio.service

Aquí verás el estado Loaded, Active, el PID, tiempo de actividad y los últimos mensajes de log, lo cual es oro para depurar errores.

Habilitar y deshabilitar servicios (también visto):

sudo systemctl enable nombre_servicio.service
sudo systemctl disable nombre_servicio.service

Iniciar, parar y reiniciar servicios de forma explícita:

sudo systemctl start nombre_servicio.service
sudo systemctl stop nombre_servicio.service
sudo systemctl restart nombre_servicio.service

Estos patrones se repiten con prácticamente cualquier servicio, desde apache2, nginx o ssh, hasta servicios de bases de datos, demonios de impresión o lo que se te ocurra.

Gestión de servicios: iniciar, recargar, detener y supervisar

En un entorno real, vas a usar systemctl para mantener servicios esenciales siempre a punto: servidores web, bases de datos, servicios de red, demonios de backup, etc. La idea es minimizar el tiempo de inactividad y aplicar cambios de configuración con el menor impacto posible.

Para iniciar un servicio que se supone que debería estar activo (por ejemplo, Apache), el comando típico sería:

sudo systemctl start apache2

Si Apache ya estaba en marcha, no notarás nada especial; si estaba parado, el demonio levantará procesos hijo y comenzará a atender peticiones. Siempre que dudes de qué ha pasado, tira de:

sudo systemctl status apache2

Cuando cambias el archivo de configuración principal o algún virtual host, sueles recargar o reiniciar el servicio. Recargar es más suave:

sudo systemctl reload apache2

Esto hace que el servicio relea ficheros de configuración sin matar procesos en curso, por lo que los usuarios apenas notan nada. Si por la razón que sea el servicio no soporta recarga, te tocará:

sudo systemctl restart apache2

En algunos casos, si el servicio está dando guerra o se ha quedado en un estado extraño, un reinicio completo libera recursos y limpia procesos zombis. Es uno de los pasos típicos de diagnóstico antes de ir a mirar logs en profundidad.

Para detener temporalmente un servicio porque estás haciendo mantenimiento o porque no lo necesitas durante un rato, simplemente:

sudo systemctl stop apache2

Eso no impide que vuelva a arrancar en el próximo reinicio si lo tienes habilitado. Si quieres que desaparezca del mapa hasta nuevo aviso, combinas stop con disable o mask según el grado de “prohibición” que quieras aplicar.

Después de cualquier operación sensible, es muy recomendable comprobar el estado del servicio y sus últimos registros con:

sudo systemctl status nombre_servicio

y, si necesitas más contexto, con journalctl, por ejemplo:

sudo journalctl -u nombre_servicio

Solución de problemas habituales con systemctl

Cuando algo falla al arrancar un servicio con systemctl, lo normal es ver mensajes del tipo “Job for X failed” o estados failed en la salida de status. La forma ordenada de proceder suele ser:

1. Mirar el estado detallado de la unidad:

sudo systemctl status nombre_servicio

Ahí verás si el servicio no arranca por fallo en el comando, por timeout, por permisos, por falta de fichero, etc. Fíjate en líneas como “Main PID exited” y en los mensajes de error reales de la aplicación.

2. Revisar los registros completos con journalctl:

sudo journalctl -u nombre_servicio

Con esto obtienes el historial de logs que ha generado la unidad, muy útil si el servicio “muere” justo después de iniciar.

3. Verificar si está habilitado cuando esperas que arranque en boot:

sudo systemctl is-enabled nombre_servicio

Si aparece como disabled, bastará con:

sudo systemctl enable nombre_servicio

4. Comprobar permisos y usuario. Algunos servicios necesitan ejecutarse como un usuario concreto o acceder a rutas determinadas. Si el archivo de unidad especifica un User= o Group= incorrecto, o la ruta en ExecStart= no existe o no es accesible, el servicio puede caer al instante.

5. Si has tocado el archivo de unidad a mano, recuerda siempre recargar la configuración de systemd con:

sudo systemctl daemon-reload

Olvidar este paso es un clásico: haces cambios, reinicias el servicio y sigues viendo el comportamiento antiguo porque systemd aún no ha leído el nuevo archivo.

Manteniendo esta rutina de comprobaciones y revisando periódicamente el estado de unidades clave, es mucho más fácil mantener un sistema Linux estable y predecible.

Como ves, systemctl se convierte en la navaja suiza para administrar servicios, unidades y estados del sistema en cualquier distribución moderna con systemd: te permite arrancar y detener demonios con precisión, controlar qué se inicia en el arranque, investigar fallos con bastante detalle, ajustar configuraciones sin machacar archivos de sistema y cambiar de un modo gráfico a uno de rescate en cuestión de segundos. Dominar estos comandos no solo te hace la vida más sencilla a la hora de gestionar servidores o escritorios Linux, también te da mucha más confianza cuando toca resolver problemas serios en producción, porque sabes exactamente qué se está ejecutando, por qué y cómo detenerlo o modificarlo de forma segura.