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 co­n­fi­gu­ra­cio­nes de systemd, lo que la convierte en una he­rra­mie­n­ta in­di­s­pe­n­sa­ble para la ad­mi­ni­s­tra­ción del sistema. Desde el control del arranque hasta la pe­r­so­na­li­za­ción de los estados del sistema, systemctl ofrece una amplia gama de funciones.

¿Qué es systemctl?

systemctl es una he­rra­mie­n­ta de línea de comandos para gestionar systemd, un sistema de init y gestor de sistemas para sistemas ope­ra­ti­vos Linux. systemd es ahora el sistema de init estándar para muchas di­s­tri­bu­cio­nes Linux o di­s­tri­bu­cio­nes de Linux para se­r­vi­do­res como Ubuntu, Debian, Fedora, Red Hat En­te­r­pri­se Linux (RHEL), CentOS, Arch Linux, Mageia o Gentoo, pero no está im­ple­me­n­ta­do uni­ve­r­sa­l­me­n­te en todas las di­s­tri­bu­cio­nes.

En el eco­si­s­te­ma systemd, systemctl desempeña un papel central en la gestión de los servicios del sistema, la co­n­fi­gu­ra­ción, el co­m­po­r­ta­mie­n­to de arranque y el ma­n­te­ni­mie­n­to del sistema. La fu­n­cio­na­li­dad de la he­rra­mie­n­ta va más allá del simple arranque y parada de servicios y ofrece un control exhau­s­ti­vo sobre casi todos los aspectos de un sistema Linux.

En el siguiente tutorial en­co­n­tra­rá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 co­m­po­ne­n­tes que se requieren después de arrancar el kernel de Linux (co­m­po­ne­n­tes ‘userland’). Además, el sistema init se utiliza para controlar efi­ca­z­me­n­te 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 ge­s­tio­na­dos por systemd. Estas unidades se cla­si­fi­can según el tipo de recurso que re­pre­se­n­tan y se definen mediante los de­no­mi­na­dos ficheros de unidad. El tipo de unidad puede re­co­no­ce­r­se por la extensión del archivo.

Cuando se gestionan servicios, las unidades de servicio que terminan con el sufijo .service son pa­r­ti­cu­la­r­me­n­te im­po­r­ta­n­tes. Sin embargo, a menudo no es necesario es­pe­ci­fi­car 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 rea­li­za­das con systemctl en Linux incluyen arrancar y parar servicios. Estas funciones son fu­n­da­me­n­ta­les 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á tra­ba­ja­n­do como usuario sin derechos de root, debe utilizar ‘sudo’:

$ sudo systemctl start application.service

Como systemd está diseñado para buscar au­to­má­ti­ca­me­n­te archivos .service para comandos de gestión de servicios, el comando también se puede in­tro­du­cir de forma si­m­pli­fi­ca­da:

$ 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 co­n­fi­gu­ra­ción, utiliza el comando ‘restart’:

$ sudo systemctl restart application.service

Si la apli­ca­ción co­rre­s­po­n­die­n­te es capaz de recargar tus ficheros de co­n­fi­gu­ra­ció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 co­n­fi­gu­ra­ción, puedes utilizar el comando ‘reload-or-restart’. La co­n­fi­gu­ra­ción se recarga si esta opción es co­m­pa­ti­ble. Si no lo es, el comando re­ini­cia­rá el servicio para aplicar la co­n­fi­gu­ra­ción ac­tua­li­za­da.

$ sudo systemctl reload-or-restart application.service

Ac­ti­va­ción y des­ac­ti­va­ción de los servicios

Mediante la ac­ti­va­ción y la des­ac­ti­va­ción de los servicios, puedes es­pe­ci­fi­car si estos deben iniciarse au­to­má­ti­ca­me­n­te o no al arrancar el sistema. Esto es es­pe­cia­l­me­n­te im­po­r­ta­n­te para el re­n­di­mie­n­to del sistema, la seguridad y la gestión de de­pe­n­de­n­cias entre distintos servicios. Para co­n­fi­gu­rar un servicio de modo que se ejecute au­to­má­ti­ca­me­n­te 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 no­r­ma­l­me­n­te puede en­co­n­trar­se en /lib/systemd/system o /etc/systemd/system, con el di­re­c­to­rio del disco duro en el que systemd busca archivos para el au­to­arra­n­que, que no­r­ma­l­me­n­te tiene lugar en /etc/systemd/system/some_target.target.wants.

$ sudo systemctl enable application.service

Para evitar que un servicio se inicie au­to­má­ti­ca­me­n­te al arrancar, utiliza ‘disable’:

$ sudo systemctl disable application.service

Esto elimina el enlace simbólico que an­te­rio­r­me­n­te es­pe­ci­fi­ca­ba que el servicio debía iniciarse au­to­má­ti­ca­me­n­te. Atención: la simple ac­ti­va­ción de un servicio no lo inicia in­me­dia­ta­me­n­te en la sesión actual. Para iniciar el servicio in­me­dia­ta­me­n­te y co­n­fi­gu­rar­lo para que se inicie au­to­má­ti­ca­me­n­te al arrancar, debes ejecutar los comandos ‘start’ y ‘enable’.

Co­m­pro­ba­ción del estado de los servicios

Con systemctl se puede mostrar in­fo­r­ma­ción detallada sobre el estado de los servicios. Esta función es es­pe­cia­l­me­n­te útil para controlar y dia­g­no­s­ti­car el estado actual de los servicios del sistema y de las apli­ca­cio­nes. Utiliza el comando ‘status’ para la co­m­pro­ba­ción:

$ systemctl status application.service

Este comando pro­po­r­cio­na una amplia gama de in­fo­r­ma­ción, in­clu­ye­n­do el estado actual del servicio (activo, inactivo, de­fe­c­tuo­so, etc.), los procesos y mensajes de registro eje­cu­ta­dos más re­cie­n­te­me­n­te, 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 es­pe­ci­fi­ca si un servicio está ac­tua­l­me­n­te activo o no:

$ systemctl is-active application.service

El estado actual suele es­pe­ci­fi­car­se como ‘activo’ si el servicio está activo, o ‘inactivo’ en caso contrario.

Puedes utilizar el comando ‘is-enabled’ para comprobar si un servicio está co­n­fi­gu­ra­do para activarse au­to­má­ti­ca­me­n­te al iniciar el sistema. Esto es es­pe­cia­l­me­n­te útil para gestionar la co­n­fi­gu­ra­ción de inicio de los servicios en un sistema Linux.

$ systemctl is-enabled application.service

El comando indica si el servicio está activado o des­ac­ti­va­do y, en co­n­se­cue­n­cia, 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 es­pe­cí­fi­co 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 in­te­n­cio­na­da­me­n­te, 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 pre­se­n­ta­dos hasta ahora se centran en la gestión de servicios in­di­vi­dua­les, pero no ofrecen una visión general del estado del sistema actual. Sin embargo, hay una gran variedad de comandos de systemctl que pro­po­r­cio­nan este tipo de in­fo­r­ma­ción.

‘list-units’ es una he­rra­mie­n­ta ú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 pre­se­n­ta­ción de esta lista incluye di­fe­re­n­tes columnas con in­fo­r­ma­ción es­pe­cí­fi­ca sobre cada unidad. Dichas columnas muestran lo siguiente:

• UNIT: el nombre de la unidad, suele ser el nombre del archivo del archivo co­rre­s­po­n­die­n­te de la unidad; p. ej., sshd.service para los daemon de SSH.
• LOAD: indica si un archivo de la unidad se ha cargado co­rre­c­ta­me­n­te; los posibles valores son ‘loaded’, ‘not-found’ o ‘error’.
• ACTIVE: el estado de actividad de la unidad; este puede tener valores como ‘active’, ‘inactive’, ‘ac­ti­va­ti­ng’ o ‘dea­c­ti­va­ti­ng’.
• SUB: el estado de actividad su­bo­r­di­na­do, 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’.
• DE­S­CRI­P­TION: una breve de­s­cri­p­ción de la unidad que suele reflejar el objetivo o la fu­n­cio­na­li­dad 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 in­di­ca­do­res adi­cio­na­les, systemctl puede co­n­fi­gu­rar­se para que también muestre in­fo­r­ma­ción ampliada. Por ejemplo, para mostrar todas las unidades cargadas por systemd in­de­pe­n­die­n­te­me­n­te de su estado de actividad actual, utiliza el indicador ‘–all’:

$ systemctl list-units --all

La salida puede refinarse aún más uti­li­za­n­do in­di­ca­do­res adi­cio­na­les como ‘–state=’ para filtrar estados es­pe­cí­fi­cos en las ca­te­go­rías LOAD, ACTIVE o SUB. Es im­po­r­ta­n­te 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 de­te­r­mi­na­dos tipos de unidades; por ejemplo, para ver solo las unidades en servicio activo:

$ systemctl list-units --type=service

Enu­me­ra­ción de todos los archivos de unidad

Para mostrar una lista de todos los archivos de unidad en Linux con systemctl (in­clu­ye­n­do aquellos que systemd no ha intentado cargar) puedes usar ‘list-unit-files’. Este comando muestra todos los archivos de unidad conocidos por systemd, in­clu­ye­n­do 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 co­n­fi­gu­ra­das las unidades co­rre­s­po­n­die­n­tes, en pa­r­ti­cu­lar con respecto a su co­m­po­r­ta­mie­n­to al iniciar el sistema. Los estados más comunes son:

• Enabled: la unidad está co­n­fi­gu­ra­da para que se active au­to­má­ti­ca­me­n­te al arrancar el sistema.
• Disabled: la unidad no está co­n­fi­gu­ra­da para que se inicie au­to­má­ti­ca­me­n­te durante el proceso de arranque.
• Masked: la unidad está co­m­ple­ta­me­n­te des­ac­ti­va­da, por lo que no puedes iniciarla ni manual ni au­to­má­ti­ca­me­n­te.
• Static: la unidad no se inicia de forma in­de­pe­n­die­n­te, 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 pri­n­ci­pa­les tareas de systemctl. Para obtener in­fo­r­ma­ción más es­pe­cí­fi­ca sobre las unidades in­di­vi­dua­les y cómo ge­s­tio­nar­las, systemctl ofrece una serie de comandos y opciones útiles.

Vi­sua­li­za­ción de un archivo de unidad

Puedes utilizar el comando ‘cat’ para mostrar el contenido de un archivo de unidad es­pe­cí­fi­co di­re­c­ta­me­n­te en el panel. Por ejemplo, para ver el archivo de unidad de un servicio como ssh.service, introduce:

$ systemctl cat ssh.service

Vi­sua­li­za­ción de de­pe­n­de­n­cias

Las de­pe­n­de­n­cias de una unidad es­pe­cí­fi­ca pueden mostrarse como una es­tru­c­tu­ra de árbol uti­li­za­n­do ‘list-de­pe­n­de­n­cies’. El comando es de la siguiente forma:

$ systemctl list-dependencies sshd.service

Por defecto, las de­pe­n­de­n­cias se muestran para las unidades ‘.target’ que re­pre­se­n­tan di­fe­re­n­tes estados del sistema. Para obtener una lista completa y recursiva de todas las de­pe­n­de­n­cias, utiliza el indicador ‘–all’.

Para mostrar las de­pe­n­de­n­cias inversas; es decir, las unidades que dependen de la unidad es­pe­ci­fi­ca­da, añade ‘–reverse’ al comando. Además, los in­di­ca­do­res ‘–before’ y ‘–after’ permiten ver las de­pe­n­de­n­cias que comienzan antes o después de la unidad en cuestión.

En­ma­s­ca­ra­mie­n­to y des­en­ma­s­ca­ra­mie­n­to de unidades

En­ma­s­ca­rar una unidad la desactiva para que no pueda iniciarse manual ni au­to­má­ti­ca­me­n­te. Esto se utiliza a menudo para asegurar que las de­pe­n­de­n­cias no inicien ac­ci­de­n­tal o au­to­má­ti­ca­me­n­te un servicio o una unidad. El en­ma­s­ca­ra­mie­n­to 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 au­to­má­ti­ca­me­n­te mientras esté en modo de en­ma­s­ca­ra­mie­n­to.

Des­en­ma­s­ca­rar cancela el estado de en­ma­s­ca­ra­mie­n­to de una unidad para que pueda volver a arrancar con no­r­ma­li­dad. El comando para des­en­ma­s­ca­rar es ‘unmask’:

$ sudo systemctl unmask nginx.service

Edición de archivos de unidad

systemctl tiene opciones para pe­r­so­na­li­zar y modificar archivos de unidad. Esta capacidad se introdujo con la versión 218 de systemd. Si utilizas el comando ‘edit’, se abre au­to­má­ti­ca­me­n­te un archivo de unidad de la unidad se­le­c­cio­na­da para su edición:

$ sudo systemctl edit nginx.service

Cuando se edita, se crea un archivo vacío para añadir o modificar in­s­tru­c­cio­nes es­pe­cí­fi­cas a la de­fi­ni­ción de una unidad. Para cada unidad, por ejemplo ‘nginx.service’, se crea una su­b­ca­r­pe­ta en el di­re­c­to­rio ‘/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 su­b­ca­r­pe­ta. Cuando systemd carga la unidad combina el contenido de este archivo de snippet con el archivo de unidad original, por lo que las in­s­tru­c­cio­nes 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 mo­di­fi­ca­cio­nes. Al salir del editor, el sistema guarda el archivo editado en ‘/etc/systemd/system’.

Para deshacer las mo­di­fi­ca­cio­nes que hayas hecho tú mismo, puedes borrar el di­re­c­to­rio de co­n­fi­gu­ra­ción ‘.d’ de la unidad o el archivo mo­di­fi­ca­do en ‘/etc/systemd/system’:

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

Un archivo de unidad co­m­ple­ta­me­n­te revisado se borra con el siguiente comando:

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

Después de eliminar el archivo o el di­re­c­to­rio, es necesario recargar systemd para que deje de hacer re­fe­re­n­cia a los archivos eli­mi­na­dos y, en su lugar, vuelva a la copia propia del sistema:

$ sudo systemctl daemon-reload

Ada­p­ta­ción del estado del sistema (Runlevel) con objetivos

Los objetivos en systemd se utilizan pri­n­ci­pa­l­me­n­te para agrupar di­fe­re­n­tes unidades con el fin de realizar estados es­pe­cí­fi­cos del sistema (similar al Runlevel en otros sistemas init). Los archivos con el sufijo ‘.target’ actúan como puntos de re­fe­re­n­cia que indican el estado de di­s­po­ni­bi­li­dad de ciertas funciones para que los usuarios puedan es­pe­ci­fi­car el estado general deseado en lugar de las unidades in­di­vi­dua­les ne­ce­sa­rias.

Un ejemplo práctico es el ‘swap.target’, que marca el estado de pre­pa­ra­ción para swap. Las unidades que pa­r­ti­ci­pan en el proceso de swap pueden si­n­cro­ni­zar­se con este objetivo mediante opciones de co­n­fi­gu­ra­ción como ‘WantedBy=’ o ‘Re­qui­re­d­By=’. Las unidades que dependen de swap, por su parte, pueden indicarlo ajustes como ‘Wants=’, ‘Requires=’ y ‘After=’ para expresar su de­pe­n­de­n­cia y secuencia de inicio en relación con swap.

Re­cu­pe­ra­ción y co­n­fi­gu­ra­ción del objetivo estándar

La re­cu­pe­ra­ción y co­n­fi­gu­ra­ción del objetivo estándar permite definir un estado del sistema estándar que tu sistema debe alcanzar en el arranque. Así en­co­n­tra­rá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 es­ta­ble­cer el objetivo estándar en ‘graphical.target’, que inicia una interfaz gráfica de usuario:

$ sudo systemctl set-default graphical.target

Enu­me­ra­ción de los objetivos di­s­po­ni­bles

Para enumerar todos los objetivos di­s­po­ni­bles 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 in­s­ta­la­dos en el sistema. Para cada objetivo se muestra la ruta y el estado actual (por ejemplo, activado o des­ac­ti­va­do).

Ai­s­la­mie­n­to de objetivos

Con ‘isolate’ puedes activar todas las unidades que estén co­ne­c­ta­das a un objetivo es­pe­cí­fi­co y, al mismo tiempo, detener todas las demás unidades que no estén co­ne­c­ta­das a él.

Su­po­n­ga­mos que estás tra­ba­ja­n­do en un entorno con el ‘graphical.target’ activo y quieres cambiar a un modo mu­l­tiu­sua­rio puro sin interfaz gráfica de usuario. En este caso, puedes des­ac­ti­var 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 de­pe­n­de­n­cias asociadas antes de aislar un objetivo. Así se evitará que procesos im­po­r­ta­n­tes se detengan in­vo­lu­n­ta­ria­me­n­te.

$ systemctl list-dependencies multi-user.target

Si has co­m­pro­ba­do 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 im­po­r­ta­n­tes

Existen objetivos es­pe­cí­fi­cos para procesos ese­n­cia­les como apagar o reiniciar el sistema. Sin embargo, en Linux, systemctl también ofrece atajos prácticos que pro­po­r­cio­nan funciones adi­cio­na­les. 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 co­ne­c­ta­dos sobre los próximos sucesos, lo que no se puede conseguir si­m­ple­me­n­te eje­cu­ta­n­do o aislando el objetivo. Es im­po­r­ta­n­te saber que muchos equipos vinculan los comandos más cortos para estas acciones con systemd para ga­ra­n­ti­zar su correcta ejecución.

Por ejemplo, el siguiente comando suele ser su­fi­cie­n­te para reiniciar el sistema:

$ sudo reboot