Cómo crear una unidad de servicio Systemd en Linux

Aunque Systemd ha sido objeto de muchas controversias, hasta el punto de que algunas distribuciones se bifurcaron solo para deshacerse de él (ver Devuan, una bifurcación de Debian que, por defecto, reemplaza a Systemd con Sysvinit), al final se ha convertido en el Sistema de inicio estándar de facto en el mundo de Linux.

En este tutorial veremos cómo se estructura un servicio Systemd y aprenderemos cómo crear uno.

En este tutorial aprenderás:

• ¿Qué es una unidad de servicio ..
• ¿Cuáles son las secciones de una unidad de servicio?.
• ¿Cuáles son las opciones más comunes que se pueden usar en cada sección?.
• ¿Cuáles son los diferentes tipos de servicio que se pueden definir?.

Requisitos y convenciones de software utilizados

El sistema init systemd

Todas las principales distribuciones, como Rhel, Centos, Fedora, Ubuntu, Debian y Archlinux, adoptaron Systemd como su sistema init. Systemd, en realidad, es más que un sistema inicial, y esa es una de las razones por las cuales algunas personas están fuertemente en contra de su diseño, que va en contra del lema de Unix bien establecido: "Haz una cosa y hazlo bien". Donde otros sistemas init usan script shell shell para administrar los servicios, Systemd utiliza su propio .servicio archivos (unidades con el .Sufijo de servicio): en este tutorial veremos cómo están estructurados y cómo crear e instalar uno.

Anatomía de una unidad de servicio

¿Qué es una unidad de servicio?? Un archivo con el .servicio El sufijo contiene información sobre un proceso administrado por Systemd. Está compuesto por tres secciones principales:

• [Unidad]: Esta sección contiene información que no está específicamente relacionada con el tipo de unidad, como la descripción del servicio
• [Servicio]: contiene información sobre el tipo específico de la unidad, un servicio en este caso
• [Instalar]: esta sección contiene información sobre la instalación de la unidad

Analicemos cada uno de ellos en detalle.

La sección [Unidad]

El [Unidad] sección de un .servicio El archivo contiene la descripción de la unidad en sí, e información sobre su comportamiento y sus dependencias: (para trabajar correctamente un servicio puede depender de otro). Aquí discutimos algunas de las opciones más relevantes que se pueden usar en esta sección

La opción "Descripción"

En primer lugar, tenemos el Descripción opción. Al usar esta opción, podemos proporcionar una descripción de la unidad. Luego aparecerá la descripción, por ejemplo, cuando llame al systemctl Comando, que devuelve una descripción general del estado de Systemd. Aquí está, como ejemplo, cómo la descripción de httpd El servicio se define en un sistema Fedora:

[Unidad] Descripción = El servidor Apache HTTP 

La opción "después"

Mediante el uso del Después Opción, podemos indicar que nuestra unidad debe iniciarse después de las unidades que proporcionamos en forma de una lista separada por el espacio. Por ejemplo, observando nuevamente el archivo de servicio donde se define el servicio web Apache, podemos ver lo siguiente:

Después = red.Target Remote-FS.Target NSS-Lookup.objetivo httpd-init.servicio

La línea anterior instruye a Systemd que inicie la unidad de servicio httpd.servicio Solo después del red, eliminar, NSS-mira objetivos y el Servicio de In-Init httpd.

Especificar dependencias duras con "requiere"

Como mencionamos brevemente anteriormente, una unidad (un servicio en nuestro caso) puede depender de otras unidades (no necesariamente unidades de "servicio") para funcionar correctamente: tales dependencias se pueden declarar utilizando el uso de la Requerimiento opción.

Si alguna de las unidades en las que depende un servicio no se inicia, la activación del servicio se detiene: es por eso que se llaman dependencias duras. En esta línea, extraído del archivo de servicio del Avahi-Demon, podemos ver cómo se declara como dependiente del Avahi-Daemon.Unidad de enchufe:

Requiere = Avahi-Daemon.enchufe

Declarar dependencias "suaves" con "deseos"

Acabamos de ver cómo declarar las llamadas dependencias "difíciles" para el servicio utilizando el Requerimiento opción; También podemos enumerar dependencias "suaves" utilizando el Quiere opción.

Cuál es la diferencia? Como dijimos anteriormente, si falla una dependencia "dura", el servicio fallará a sí mismo; Sin embargo, una falla de cualquier dependencia "blanda" no influye en lo que le sucede a la unidad dependiente. En el ejemplo proporcionado, podemos ver cómo el estibador.servicio la unidad tiene una dependencia suave de la setup de almacenamiento.servicio uno:

[Unidad] deseos = Docker-Storage-setup.servicio 

La sección [Servicio]

En el [Servicio] sección de un servicio Unidad, podemos especificar las cosas como el comando que se ejecutará cuando se inicia el servicio, o el tipo de servicio en sí. Echemos un vistazo a algunos de ellos.

Comenzar, detener y recargar un servicio

Se puede iniciar, detener, reiniciar o volver a cargar un servicio. Los comandos que se ejecutarán al realizar cada una de estas acciones se pueden especificar utilizando las opciones relacionadas en el [Servicio] sección.

El comando que se ejecutará cuando se inicia un servicio, se declara utilizando el Exectard opción. El argumento transmitido a la opción también puede ser el camino hacia un script. Opcionalmente, podemos declarar comandos que se ejecutarán antes y después de que se inicie el servicio, utilizando el Execstartpre y Execstartpost opciones respectivamente. Aquí está el comando utilizado para iniciar el servicio NetworkManager:

[Servicio] execstart =/usr/sbin/networkmanager-no-daemon 

De manera similar, podemos especificar el comando que se ejecutará cuando un servicio se vuelva a cargar o se detiene, utilizando el Execstop y Execreload opción. Del mismo modo a lo que sucede con Execstartpost, Se puede especificar un comando o múltiples comandos después de que se detenga un proceso con el Execstoppost opción.

El tipo de servicio

Systemd define y distinga entre algún tipo diferente de servicios dependiendo de su comportamiento esperado. El tipo de servicio se puede definir utilizando el Tipo opción, proporcionando uno de estos valores:

• simple
• bifurcación
• un trago
• dBUS
• notificar

El tipo predeterminado de un servicio, si el Tipo y Juego de busca no se definen las opciones, pero se proporciona un comando a través del Exectard opción, es simple. Cuando se establece este tipo de servicio, el comando declarado en Exectard se considera el principal proceso/servicio.

El bifurcación El tipo funciona de manera diferente: el comando proporcionado con Exectard se espera que bifurca y lance un proceso infantil, que se convertirá en el proceso/servicio principal. El proceso principal se espera que muera una vez que termine el proceso de inicio.

El un trago El tipo se usa como predeterminado si el Tipo y Exectard Las opciones no están definidas. Funciona bastante como simple: La diferencia es que se espera que el proceso finalice su trabajo antes de que sean otras unidades. La unidad, sin embargo, todavía se considera "activa" incluso después de que sale el comando, si el Permanecer La opción está configurada en "Sí" (el valor predeterminado es "no").

El siguiente tipo de servicio es dBUS. Si se utiliza este tipo de servicio, se espera que el demonio obtenga un nombre de DBUS, como se especifica en el Juego de busca opción, que en este caso, se vuelve obligatoria. Por el resto funciona como el simple tipo. Sin embargo, las unidades consecuentes se lanzan solo después de adquirir el nombre de DBUS.

Otro proceso funciona de manera similar a simple, y es notificar: La diferencia es que se espera que el demonio envíe una notificación a través del sd_notify función. Solo una vez que se envía esta notificación, se lanzan las unidades consecuentes.

Establecer tiempos de espera del proceso

Mediante el uso de opciones específicas, es posible definir algunos tiempos de espera para el servicio. Empecemos con Reinicio: Al usar esta opción, podemos configurar la cantidad de tiempo (por defecto en segundos) que Systemd debe esperar antes de reiniciar un servicio. Un tiempo de tiempo también se puede usar como un valor para esta opción, como "5min 20s". El valor predeterminado es 100 ms.

El Tiempo de espera y Tiempo de espera Las opciones se pueden usar para especificar, respectivamente, el tiempo de espera para un inicio de servicio y detener, en segundos. En el primer caso, si después del tiempo de espera especificado del proceso de inicio del demonio no se completa, se considerará fallado.

En el segundo caso, si se va a detener un servicio pero no se cancela después del tiempo de espera especificado, primero un Siglo y luego, después de la misma cantidad de tiempo, un Sigkill Se envían señal. Ambas opciones también aceptan un tiempo de tiempo como un valor y se pueden configurar a la vez, con un atajo: Tiempo de espera. Si infinidad se proporciona como un valor, los tiempos de espera están deshabilitados.

Finalmente, podemos configurar el límite por la cantidad de tiempo que puede ejecutar un servicio, utilizando el RuntimeMaxSec. Si un servicio excede este tiempo de espera, se termina y se considera como fallido.

La sección [Instalar]

En el [instalar] Sección, podemos usar opciones relacionadas con la instalación del servicio. Por ejemplo, usando el Alias Opción, podemos especificar una lista separada por el espacio de alias que se utilizarán para el servicio al usar los comandos SystemCTL (excepto permitir).

Del mismo modo a lo que sucede con el Requerimiento y Quiere opciones en el [Unidad] sección, para establecer dependencias, en el [instalar] sección, podemos usar Requerido por y Buscado por. En ambos casos, declaramos una lista de unidades que dependen de la que estamos configurando: con la opción anterior dependerán de ello, con las últimas se considerarán solo como dependientes débiles. Por ejemplo:

[Instalar] WantedBy = Multiuser.objetivo 

Con la línea anterior declaramos que el multi usuario El objetivo tiene una dependencia suave de nuestra unidad. En la terminología systemd, las unidades que terminan con el .objetivo sufijo, puede asociarse con lo que se llamó tiempos de ejecución en otros sistemas init como Sysvinit. En nuestro caso, entonces, el objetivo múltiple de usuario, cuando se alcanza, debe incluir nuestro servicio.

Creación e instalación de una unidad de servicio

Básicamente, hay dos lugares en el sistema de archivos donde se instalan unidades de servicio Systemd: /usr/lib/systemd/sistema y /etc/systemd/sistema. La ruta anterior se utiliza para los servicios proporcionados por los paquetes instalados, mientras que la segunda puede ser utilizada por el administrador del sistema para sus propios servicios que pueden anular los predeterminados.

Creemos un ejemplo de servicio personalizado. Supongamos que queremos crear un servicio que deshabilite la función Wake-On-Lan en una interfaz Ethernet específica (ENS5F5 en nuestro caso) cuando se inicia, y la vuelva a permitir cuando se detiene. Podemos usar el Ethool comandar para lograr la tarea principal. Así es como podría verse nuestro archivo de servicio:

[Unidad] Descripción = Force Ens5f5 La interfaz Ethernet a 100Mbps requiere = red.Target After = Network.Target [Service] type = oneShot RESTAFTEREXIT = YES EXECSTART =/usr/sbin/EthTool -S Ens5f5 Wol D ExecStop =/usr/Sbin/EthTool -S Ens5f5 Wol G [Instalar] WantedBy = Multi -User.objetivo 

Establecimos una simple descripción de la unidad y declaramos que el servicio depende de la red.objetivo unidad y debe lanzarse después de que se alcance. En el [Servicio] sección establecemos el tipo de servicio como un trago, e instruido en el sistema de Systemd que considere que el servicio está activo después de ejecutar el comando, utilizando el Permanecer opción. También definimos los comandos que se ejecutarán cuando el servicio se inicia y se detenga. Finalmente, en el [Instalar] Sección Básicamente declaramos que nuestro servicio debe incluirse en el multi usuario objetivo.

Para instalar el servicio copiaremos el archivo en el /etc/systemd/sistema directorio como lirón.servicio, de lo que lo comenzaremos:

$ sudo cp wol.servicio/etc/systemd/system && sudo systemctl start wol.servicio

Podemos verificar que el servicio esté activo, con el siguiente comando:

$ systemctl is-active wol.servicio activo 

La salida del comando, como se esperaba, es activo. Ahora para verificar que "Wake On Lan" se ha establecido en d, Y ahora está deshabilitado, podemos ejecutar:

$ sudo ethtool Ens5f5 | Grep Wake-on Supports Wake-On: PG Wake-On: D 

Ahora, detener el servicio debería producir el resultado inverso y volver a habilitar WOL:

$ sudo systemctl stop wol.servicio && sudo ethtool Ens5f5 | Grep Wake-on Supports Wake-On: PG Wake-On: G 

Conclusiones

En este tutorial vimos cómo se compone un archivo de servicio Systemd, cuáles son sus secciones y algunas de las opciones que se pueden usar en cada uno de ellos. Aprendimos a configurar una descripción del servicio, definir sus dependencias y declarar los comandos que deben ejecutarse cuando se inicia, detener o volver a cargar.

Dado que Systemd, lee o no, se ha convertido en el sistema init estándar en el mundo de Linux, es importante familiarizarse con su forma de hacer las cosas. La documentación oficial de SystemD Services se puede encontrar en el sitio web de Freedesktop. También podría estar interesado en leer nuestro artículo sobre la gestión de servicios con Systemd.

Tutoriales de Linux relacionados:

• Cosas para instalar en Ubuntu 20.04
• Cosas que hacer después de instalar Ubuntu 20.04 fossa focal Linux
• Cómo bloquear Linux
• Mint 20: Mejor que Ubuntu y Microsoft Windows?
• Descarga de Linux
• Sistema colgado de Linux? Cómo escapar a la línea de comando y ..
• Cosas que hacer después de instalar Ubuntu 22.04 Jellyfish de Jammy ..
• Una introducción a la automatización, herramientas y técnicas de Linux
• Comandos de Linux: los 20 comandos más importantes que necesitas ..
• Comandos básicos de Linux