Cómo escribir un archivo systemd .service ejecutando systemd-tmpfiles

Necesito ejecutar systemd-tmpfiles --createdurante el proceso de arranque con una distribución systemd. Entonces necesito crear un archivo systemd .service haciendo este trabajo.

En esta pregunta, puede leer todos los detalles sobre lo que necesito y por qué: ¿Cómo funciona systemd-tmpfiles?

He leído algunos documentos al respecto y estoy escribiendo la siguiente prueba:

[Unit]
Description=Execute tmpfiles to disable usb-wakeup # see details in the link above
Requires=multi-user.target # see details in the link above
After=multi-user.target    # see details in the link above

[Service]
Type=oneshot
ExecStart=/usr/bin/systemd-tmpfiles --create

[Install]
WantedBy=multi-user.target

Pero no estoy seguro, porque systemd-tmpfilesno es un programa simple sino una parte del sistema en sí. No me gustaría romper mi sistema.

¿Algún consejo sobre un archivo .service correcto?

[Esto no aborda directamente el problema de systemd-tmpfiles, pero creo que ya ha reconocido que en este caso particular es mejor que solo use echo.]

En primer lugar, "multi-user.target" puede o no ser lo que desea usar. Si está familiarizado con el concepto de niveles de ejecución de material de inicio de estilo SysV, multiusuario es el equivalente del sistema de nivel de ejecución 3, que es un sistema multiusuario que arranca en una consola, no en una GUI. El equivalente del nivel de ejecución 5, que arranca en X, es graphical.target . El valor predeterminado está determinado por un enlace simbólico en /etc/systemd/system(y / o /lib/systemd/system; el que está en el sistema /etcanulará al que está en /lib) llamado default.target , use ls para encontrar dónde apunta:

»ls -l /etc/systemd/system/default.target
default.target -> /usr/lib/systemd/system/multi-user.target

Para los escritorios normales de Linux, esto será graphical.target. En realidad, esto no es importante si desea que el servicio de arranque que está creando se inicie independientemente de cuál sea el nivel de ejecución / destino predeterminado; en ese caso, solo podemos usar default.target y no preocuparnos por qué es un alias. Sin embargo, si usa varios usuarios y su valor predeterminado es gráfico, su servicio no se realizará.

Dependiendo del servicio, puede haber objetivos o servicios más apropiados y específicos con los que desea iniciar este. Según su otra pregunta, default.target probablemente esté bien. Como nota, la diferencia entre un "objetivo" y un "servicio" es que un servicio contiene una [Service]sección que realmente ejecuta un proceso; un objetivo es solo una forma de agrupar servicios a través de varias directivas "depende" y "requiere"; no hace nada por sí solo más allá de activar otros objetivos o servicios.

Cuando se inicia un servicio está determinado por qué otros servicios dependen explícitamente de él. En el caso de un evento simple y autónomo como este que queremos que llegue tarde en el proceso de arranque, podemos usar esta combinación de directivas:

[Unit]
After=default.target

[Install]
WantedBy=default.target

La sección "Instalar" se usa cuando se instala el servicio; "WantedBy" especifica un objetivo con el que queremos que se incluya este servicio (lo que significa que se ejecutará si ese objetivo lo hace, pero nb. Esto no determina cuándo se ejecutará en relación con otros ). Dado que realmente queremos que este servicio se ejecute más tarde que antes, especificamos una cláusula "Después". En realidad, esto no necesita ser el mismo que el objetivo WantedBy (por lo general, no lo es) y puede omitirse por completo si no le importa cuándo sucede; Solo lo uso con la sospecha de que la mayoría de las otras cosas se ejecutarán en relación con cosas que están encadenadas en algún lugar a algo que ha especificado Before=default.target(que también podríamos haber usado; las necesidades de un objetivo se evalúan antes de que se ejecute el objetivo).

Por ejemplo, solo haré eco de "hello world" en la consola. El servicio en sí se describe en la [Service]sección:

[Service]
Type=forking
ExecStart=/usr/local/bin/helloworld

El comando necesita una ruta completa. La razón por la que no solo utilicé /usr/bin/echo "hello world"es que no funcionará (la salida va a / dev / null, creo), y aunque un servicio que hace una echo "hello world" > /dev/consolevoluntad, la experimentación demuestra que el uso de la redirección de shell en una directiva ExecStart no funcionará . Por lo tanto / usr / local / bin / holamundo es un script de shell con esa línea uno, echo "hello world" > /dev/console.

Tenga en cuenta el Type=forking, que es necesario para un script de shell.

Nuestro archivo de servicio completo, mínimo es sólo esas tres secciones ( [Unit], [Service]y [Install]). Para instalar, coloque el archivo o un enlace simbólico en / etc / systemd / system o / usr / lib / systemd / system, y:

systemctl --system enable helloworld

Debería imprimir ln -s .... Esto no ejecuta el servicio, solo lo configura para ejecutarse en el arranque como se discutió anteriormente.

Eso es todo en pocas palabras. man systemd.unity man systemd.servicetener mas detalles.

Para el servicio systemd-tmpfiles: debe enviarse con su distribución, pero siempre puede obtener el archivo de servicio del repositorio git ascendente