systemctl: gestión de servicios y unidades de systemd

En Linux, systemctl desempeña un papel central en la gestión del sistema init y el gestor de servicios systemd. Con systemctl, los usuarios tienen control sobre los servicios, unidades y configuraciones de systemd, lo que la convierte en una herramienta indispensable para la administración del sistema. Desde el control del arranque hasta la personalización de los estados del sistema, systemctl ofrece una amplia gama de funciones.

¿Qué es systemctl?

systemctl es una herramienta de línea de comandos para gestionar systemd, un sistema de init y gestor de sistemas para sistemas operativos Linux. systemd es ahora el sistema de init estándar para muchas distribuciones Linux o distribuciones de Linux para servidores como Ubuntu, Debian, Fedora, Red Hat Enterprise Linux (RHEL), CentOS, Arch Linux, Mageia o Gentoo, pero no está implementado universalmente en todas las distribuciones.

En el ecosistema systemd, systemctl desempeña un papel central en la gestión de los servicios del sistema, la configuración, el comportamiento de arranque y el mantenimiento del sistema. La funcionalidad de la herramienta va más allá del simple arranque y parada de servicios y ofrece un control exhaustivo sobre casi todos los aspectos de un sistema Linux.

En el siguiente tutorial encontrarás ejemplos prácticos de código y comandos de Linux para usar systemctl en base a Ubuntu 22.04.

Gestión de servicios

El objetivo principal del sistema init es iniciar los componentes que se requieren después de arrancar el kernel de Linux (componentes ‘userland’). Además, el sistema init se utiliza para controlar eficazmente los servicios y daemons en un servidor en cualquier momento durante la ejecución del sistema.

Dentro de systemd, la mayoría de los procesos se centran en las conocidas unidades; es decir, recursos que son gestionados por systemd. Estas unidades se clasifican según el tipo de recurso que representan y se definen mediante los denominados ficheros de unidad. El tipo de unidad puede reconocerse por la extensión del archivo.

Cuando se gestionan servicios, las unidades de servicio que terminan con el sufijo .service son particularmente importantes. Sin embargo, a menudo no es necesario especificar este sufijo para los comandos de gestión de servicios, ya que systemd es capaz de reconocer que estos comandos suelen referirse a servicios.

Arranque y parada de servicios

Las tareas más comunes realizadas con systemctl en Linux incluyen arrancar y parar servicios. Estas funciones son fundamentales para la gestión del sistema y le permiten mantener el control sobre los procesos que se ejecutan en un sistema. Para arrancar un servicio, utiliza el comando ‘start’. Si está trabajando como usuario sin derechos de root, debe utilizar ‘sudo’:

$ sudo systemctl start application.service

Como systemd está diseñado para buscar automáticamente archivos .service para comandos de gestión de servicios, el comando también se puede introducir de forma simplificada:

$ sudo systemctl start application

Por ejemplo, para arrancar el servidor web Apache, introduce:

$ sudo systemctl start apache2

Si quieres detener un servicio en ejecución, utiliza ‘stop’:

$ sudo systemctl stop application.service

Reinicio y recarga

Para reiniciar un servicio, lo que suele ser necesario tras un cambio de configuración, utiliza el comando ‘restart’:

$ sudo systemctl restart application.service

Si la aplicación correspondiente es capaz de recargar tus ficheros de configuración sin reiniciar, se puede utilizar el comando ‘reload’ para iniciar este proceso:

$ sudo systemctl reload application.service

Ante la duda de si un servicio ofrece la opción de recargar tu configuración, puedes utilizar el comando ‘reload-or-restart’. La configuración se recarga si esta opción es compatible. Si no lo es, el comando reiniciará el servicio para aplicar la configuración actualizada.

$ sudo systemctl reload-or-restart application.service

Activación y desactivación de los servicios

Mediante la activación y la desactivación de los servicios, puedes especificar si estos deben iniciarse automáticamente o no al arrancar el sistema. Esto es especialmente importante para el rendimiento del sistema, la seguridad y la gestión de dependencias entre distintos servicios. Para configurar un servicio de modo que se ejecute automáticamente al arrancar el sistema, utiliza el comando ‘enable’:

$ sudo systemctl enable application.service

Cuando se ejecuta este proceso se crea un enlace simbólico. Este enlace conecta la copia del archivo de servicio del sistema, la cual normalmente puede encontrarse en /lib/systemd/system o /etc/systemd/system, con el directorio del disco duro en el que systemd busca archivos para el autoarranque, que normalmente tiene lugar en /etc/systemd/system/some_target.target.wants.

$ sudo systemctl enable application.service

Para evitar que un servicio se inicie automáticamente al arrancar, utiliza ‘disable’:

$ sudo systemctl disable application.service

Esto elimina el enlace simbólico que anteriormente especificaba que el servicio debía iniciarse automáticamente. Atención: la simple activación de un servicio no lo inicia inmediatamente en la sesión actual. Para iniciar el servicio inmediatamente y configurarlo para que se inicie automáticamente al arrancar, debes ejecutar los comandos ‘start’ y ‘enable’.

Comprobación del estado de los servicios

Con systemctl se puede mostrar información detallada sobre el estado de los servicios. Esta función es especialmente útil para controlar y diagnosticar el estado actual de los servicios del sistema y de las aplicaciones. Utiliza el comando ‘status’ para la comprobación:

$ systemctl status application.service

Este comando proporciona una amplia gama de información, incluyendo el estado actual del servicio (activo, inactivo, defectuoso, etc.), los procesos y mensajes de registro ejecutados más recientemente, la jerarquía cgroup y las primeras líneas de registro.

Para comprobar el estado de actividad actual de un servicio en Linux con systemctl, se utiliza ‘is-active’. Este comando especifica si un servicio está actualmente activo o no:

$ systemctl is-active application.service

El estado actual suele especificarse como ‘activo’ si el servicio está activo, o ‘inactivo’ en caso contrario.

Puedes utilizar el comando ‘is-enabled’ para comprobar si un servicio está configurado para activarse automáticamente al iniciar el sistema. Esto es especialmente útil para gestionar la configuración de inicio de los servicios en un sistema Linux.

$ systemctl is-enabled application.service

El comando indica si el servicio está activado o desactivado y, en consecuencia, establece el código de salida en ‘0’ o ‘1’ en función de la respuesta.

También puedes utilizar el comando ‘is-failed’ para comprobar si un servicio específico tiene un estado de error:

$ systemctl is-failed application.service

Si la ejecución tiene éxito, aparece ‘active’ y si hay un error, aparece ‘failed’. Si la unidad se ha detenido intencionadamente, puede aparecer como respuesta ‘unknown’ o ‘inactive’. Un estado de salida ‘0’ indica que se ha producido un error, mientras que ‘1’ indica cualquier otro estado.

Resumen mediante el estado del sistema

Los comandos presentados hasta ahora se centran en la gestión de servicios individuales, pero no ofrecen una visión general del estado del sistema actual. Sin embargo, hay una gran variedad de comandos de systemctl que proporcionan este tipo de información.

‘list-units’ es una herramienta útil para obtener una visión general de las unidades actuales en Linux:

$ systemctl list-units

Cuando se ejecuta el comando, systemctl muestra una lista de unidades que gestiona systemd. La presentación de esta lista incluye diferentes columnas con información específica sobre cada unidad. Dichas columnas muestran lo siguiente:

• UNIT: el nombre de la unidad, suele ser el nombre del archivo del archivo correspondiente de la unidad; p. ej., sshd.service para los daemon de SSH.
• LOAD: indica si un archivo de la unidad se ha cargado correctamente; los posibles valores son ‘loaded’, ‘not-found’ o ‘error’.
• ACTIVE: el estado de actividad de la unidad; este puede tener valores como ‘active’, ‘inactive’, ‘activating’ o ‘deactivating’.
• SUB: el estado de actividad subordinado, el cual ofrece detalles sobre el estado de la unidad; p. ej., una unidad ‘active’ podría tener un estado SUB de ‘running’, ‘exited’ o ‘failed’.
• DESCRIPTION: una breve descripción de la unidad que suele reflejar el objetivo o la funcionalidad de la unidad.

Sin embargo, el comando muestra solo unidades activas por defecto, por lo que la columna LOAD de la salida suele mostrar ‘loaded’ y la columna ACTIVE ‘active’. Con indicadores adicionales, systemctl puede configurarse para que también muestre información ampliada. Por ejemplo, para mostrar todas las unidades cargadas por systemd independientemente de su estado de actividad actual, utiliza el indicador ‘–all’:

$ systemctl list-units --all

La salida puede refinarse aún más utilizando indicadores adicionales como ‘–state=’ para filtrar estados específicos en las categorías LOAD, ACTIVE o SUB. Es importante conservar el indicador ‘–all’ para que también se muestren las unidades inactivas:

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

También puedes utilizar el filtro ‘–type=’ para mostrar solo determinados tipos de unidades; por ejemplo, para ver solo las unidades en servicio activo:

$ systemctl list-units --type=service

Enumeración de todos los archivos de unidad

Para mostrar una lista de todos los archivos de unidad en Linux con systemctl (incluyendo aquellos que systemd no ha intentado cargar) puedes usar ‘list-unit-files’. Este comando muestra todos los archivos de unidad conocidos por systemd, incluyendo servicios, sockets, objetivos, etc.

$ systemctl list-units-files

El comando muestra varios estados de los archivos de unidad. Estos estados indican cómo están configuradas las unidades correspondientes, en particular con respecto a su comportamiento al iniciar el sistema. Los estados más comunes son:

• Enabled: la unidad está configurada para que se active automáticamente al arrancar el sistema.
• Disabled: la unidad no está configurada para que se inicie automáticamente durante el proceso de arranque.
• Masked: la unidad está completamente desactivada, por lo que no puedes iniciarla ni manual ni automáticamente.
• Static: la unidad no se inicia de forma independiente, sino que suele depender de otra unidad y solo se inicia en este contexto

Gestión de las unidades

La gestión de las unidades es una de las principales tareas de systemctl. Para obtener información más específica sobre las unidades individuales y cómo gestionarlas, systemctl ofrece una serie de comandos y opciones útiles.

Visualización de un archivo de unidad

Puedes utilizar el comando ‘cat’ para mostrar el contenido de un archivo de unidad específico directamente en el panel. Por ejemplo, para ver el archivo de unidad de un servicio como ssh.service, introduce:

$ systemctl cat ssh.service

Visualización de dependencias

Las dependencias de una unidad específica pueden mostrarse como una estructura de árbol utilizando ‘list-dependencies’. El comando es de la siguiente forma:

$ systemctl list-dependencies sshd.service

Por defecto, las dependencias se muestran para las unidades ‘.target’ que representan diferentes estados del sistema. Para obtener una lista completa y recursiva de todas las dependencias, utiliza el indicador ‘–all’.

Para mostrar las dependencias inversas; es decir, las unidades que dependen de la unidad especificada, añade ‘–reverse’ al comando. Además, los indicadores ‘–before’ y ‘–after’ permiten ver las dependencias que comienzan antes o después de la unidad en cuestión.

Enmascaramiento y desenmascaramiento de unidades

Enmascarar una unidad la desactiva para que no pueda iniciarse manual ni automáticamente. Esto se utiliza a menudo para asegurar que las dependencias no inicien accidental o automáticamente un servicio o una unidad. El enmascaramiento se realiza creando un enlace simbólico del archivo de unidad afectado a ‘/dev/null’ con el comando ‘mask’:

$ sudo systemctl mask nginx.service

Esto garantiza que el servicio Nginx no pueda iniciarse manual ni automáticamente mientras esté en modo de enmascaramiento.

Desenmascarar cancela el estado de enmascaramiento de una unidad para que pueda volver a arrancar con normalidad. El comando para desenmascarar es ‘unmask’:

$ sudo systemctl unmask nginx.service

Edición de archivos de unidad

systemctl tiene opciones para personalizar y modificar archivos de unidad. Esta capacidad se introdujo con la versión 218 de systemd. Si utilizas el comando ‘edit’, se abre automáticamente un archivo de unidad de la unidad seleccionada para su edición:

$ sudo systemctl edit nginx.service

Cuando se edita, se crea un archivo vacío para añadir o modificar instrucciones específicas a la definición de una unidad. Para cada unidad, por ejemplo ‘nginx.service’, se crea una subcarpeta en el directorio ‘/etc/systemd/system’ con el nombre del archivo con ‘.d’ añadido; en este caso ‘nginx.service.d’.

El archivo ‘override.conf’ se crea en esta subcarpeta. Cuando systemd carga la unidad combina el contenido de este archivo de snippet con el archivo de unidad original, por lo que las instrucciones del snippet tienen prioridad. Para procesar el archivo de unidad completo se puede utilizar el indicador ‘–full’:

$ sudo systemctl edit --full nginx.service

Con ‘–full’ se abre el archivo de unidad existente en un editor para realizar modificaciones. Al salir del editor, el sistema guarda el archivo editado en ‘/etc/systemd/system’.

Para deshacer las modificaciones que hayas hecho tú mismo, puedes borrar el directorio de configuración ‘.d’ de la unidad o el archivo modificado en ‘/etc/systemd/system’:

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

Un archivo de unidad completamente revisado se borra con el siguiente comando:

$ sudo rm /etc/systemd/system/nginx.service

Después de eliminar el archivo o el directorio, es necesario recargar systemd para que deje de hacer referencia a los archivos eliminados y, en su lugar, vuelva a la copia propia del sistema:

$ sudo systemctl daemon-reload

Adaptación del estado del sistema (Runlevel) con objetivos

Los objetivos en systemd se utilizan principalmente para agrupar diferentes unidades con el fin de realizar estados específicos del sistema (similar al Runlevel en otros sistemas init). Los archivos con el sufijo ‘.target’ actúan como puntos de referencia que indican el estado de disponibilidad de ciertas funciones para que los usuarios puedan especificar el estado general deseado en lugar de las unidades individuales necesarias.

Un ejemplo práctico es el ‘swap.target’, que marca el estado de preparación para swap. Las unidades que participan en el proceso de swap pueden sincronizarse con este objetivo mediante opciones de configuración como ‘WantedBy=’ o ‘RequiredBy=’. Las unidades que dependen de swap, por su parte, pueden indicarlo ajustes como ‘Wants=’, ‘Requires=’ y ‘After=’ para expresar su dependencia y secuencia de inicio en relación con swap.

Recuperación y configuración del objetivo estándar

La recuperación y configuración del objetivo estándar permite definir un estado del sistema estándar que tu sistema debe alcanzar en el arranque. Así encontrarás el objetivo estándar de tu sistema:

$ systemctl get-default
Output
multi-user.target

Si quieres cambiar el objetivo estándar, utiliza el comando ‘set-default’ junto con el nombre del objetivo. Utiliza el siguiente comando para establecer el objetivo estándar en ‘graphical.target’, que inicia una interfaz gráfica de usuario:

$ sudo systemctl set-default graphical.target

Enumeración de los objetivos disponibles

Para enumerar todos los objetivos disponibles en tu sistema, puedes utilizar el siguiente comando:

$ systemctl list-unit-files --type=target

Se muestra una lista de todos los archivos de unidad de objetivo instalados en el sistema. Para cada objetivo se muestra la ruta y el estado actual (por ejemplo, activado o desactivado).

Aislamiento de objetivos

Con ‘isolate’ puedes activar todas las unidades que estén conectadas a un objetivo específico y, al mismo tiempo, detener todas las demás unidades que no estén conectadas a él.

Supongamos que estás trabajando en un entorno con el ‘graphical.target’ activo y quieres cambiar a un modo multiusuario puro sin interfaz gráfica de usuario. En este caso, puedes desactivar el sistema gráfico aislando el ‘multi-user.target’. Como ‘graphical.target’ depende de ‘multi-user.target’, pero no al revés, todos los servicios gráficos se detienen con el cambio.

Sin embargo, debes comprobar las dependencias asociadas antes de aislar un objetivo. Así se evitará que procesos importantes se detengan involuntariamente.

$ systemctl list-dependencies multi-user.target

Si has comprobado las unidades activas que quieres conservar y estás de acuerdo con ellas, puedes aislar el objetivo deseado:

$ sudo systemctl isolate multi-user.target

Uso de atajos para sucesos importantes

Existen objetivos específicos para procesos esenciales como apagar o reiniciar el sistema. Sin embargo, en Linux, systemctl también ofrece atajos prácticos que proporcionan funciones adicionales. Por ejemplo, para poner el sistema en modo rescate (Single-User-Modus), basta con utilizar ‘rescue’ en lugar de ‘isolate rescue.target’.

$ sudo systemctl rescue

Puedes detener el sistema con ‘halt’:

$ sudo systemctl halt

Puedes iniciar un apagado completo con ‘poweroff’:

$ sudo systemctl poweroff

Con ‘reboot’ inicias un reinicio:

$ sudo systemctl reboot

Estos comandos informan a los usuarios conectados sobre los próximos sucesos, lo que no se puede conseguir simplemente ejecutando o aislando el objetivo. Es importante saber que muchos equipos vinculan los comandos más cortos para estas acciones con systemd para garantizar su correcta ejecución.

Por ejemplo, el siguiente comando suele ser suficiente para reiniciar el sistema:

$ sudo reboot