Mejores prácticas para Wants= vs WantedBy= en archivos unitarios Systemd

Mejores prácticas para Wants= vs WantedBy= en archivos unitarios Systemd

Por lo que puedo decir de la documentación desistemadWants=y realiza la misma función , WantedBy=excepto que el primero se coloca en el archivo de la unidad dependiente y viceversa. (Eso, WantedBy=crea el unit.type.wantsdirectorio y lo llena con enlaces simbólicos).

DeDigitalOcean: comprensión de las unidades Systemd y los archivos de unidades:

La WantedBy=directiva... le permite especificar una relación de dependencia de manera similar a como Wants=lo hace la directiva en la [Unit]sección. La diferencia es que esta directiva se incluye en la unidad auxiliar, lo que permite que la unidad primaria listada permanezca relativamente limpia.

¿Se trata realmente de mantener "limpio" un archivo unitario? ¿Cuál es la mejor práctica para utilizar estas dos directivas? Es decir, si el servicio alfa "quiere" el servicio beta, ¿cuándo debería usarlo Wants=beta.servicey alpha.servicecuándo debería WantedBy=alpha.servicepreferirlo beta.service?

Respuesta1

Funcionalmente

Wantsestá en la Unitsección y WantedByestá en el Install.

El proceso de inicio systemdno procesa/utiliza la Installsección en absoluto. En su lugar, se debe crear un enlace simbólico en formato multi-user.target.wants. Por lo general, esto lo hace la utilidad systemctlque lee la Installsección.

En resumen,WantedByes afectado por systemctl enable/ systemctl disable.

Lógicamente

Considere cuál de los servicios debería "conocer" o estar "consciente" del otro. Por ejemplo, un uso común de WantedBy:

[Install]
WantedBy=multi-user.target

Alternativamente, eso podría estar en multi-user.target:

[Unit]
Wants=nginx.service

Pero esa segunda forma no tiene sentido. Lógicamente, nginx.service conoce el objetivo multiusuario definido por el sistema, y ​​no al revés.

Entonces, en su ejemplo, si el autor de alfa conoce la versión beta, entonces alfa Wantsbeta. Si el autor de beta conoce alfa, entonces beta es WantedByalfa.

Para ayudarle a decidir, puede considerar qué servicio se puede instalar (por ejemplo, desde un administrador de paquetes) sin que el otro esté presente.

Directorios de configuración

Como otra herramienta más en su caja, sepa que los archivos systemd también se pueden ampliar con directorios de configuración: /etc/systemd/system/myservice.service.d/extension.conf

Esto le permite agregar dependencias en las que ningún servicio fue creado originalmente para conocer el otro. A menudo uso esto con montajes, donde (por ejemplo) ni nginx ni el montaje necesitan conocimiento explícito del otro, pero yo, como administrador del sistema, entiendo la dependencia. Entonces creo nginx.service.d/mymount.confcon Wants=mnt-my.mount.

Respuesta2

Estos no son funcionalmente idénticos. La Wants=configuración (y los archivos de enlace simbólico) es la dependencia. La WantedBy=configuración controla la creación/destrucción de dicha dependencia cuando un servicio está habilitado/deshabilitado.

Entonces no haymejorpráctica. haycorrectopráctica. Sólo uno de los dos tiene la funcionalidad correcta para una situación determinada. O se pretende tener una dependencia persistente que siempre exista, o se pretende tener una dependencia transitoria que se pueda activar y desactivar con enable/ disable.

información relacionada