bifurcación systemd vs simple?

Estoy escribiendo mi primer systemdarchivo de unidad.

Para Type, hay algunas opciones: forking, simple, etc. He leído la documentación de RedHat sobre este tema (Tabla 9.9), pero todavía no estoy seguro cuando debería usar la opción.

¿Alguna pauta?

Cuando inicia el servicio manualmente desde la línea de comandos (sin usar el nohupcomando de prefijo o el &sufijo para ejecutarlo en segundo plano, o en otras palabras, simplemente ejecute el comando que pondría en la ExecStart=línea del .servicearchivo), ¿qué sucede?

a) Si el servicio se inicia y sigue ejecutándose, y el mensaje no vuelve hasta que presiona Control-C o detiene el servicio de alguna otra manera: entonces Type = simplees la opción correcta.

b) Si la solicitud regresa pero el servicio sigue ejecutándose en segundo plano (es decir, el servicio se demoniza solo), entonces Type = forkinges la opción correcta.

c) Si el servicio hace su trabajo y regresa al indicador sin dejar nada en ejecución (es decir, el servicio solo ajusta algunas configuraciones del kernel, envía un comando a otra cosa o hace algo similar), entonces Type = oneshotprobablemente sea la opción correcta. En este caso, ExecStartel servicio podría ser el comando para "configurar" algo, y ExecStopsería el comando correspondiente para "desarmarlo". Por lo general, este tipo se beneficia RemainAfterExit=true, por lo que systemd realizará un seguimiento del "estado" de este servicio de acuerdo a si la cosa se "configuró" o "desarmó" más recientemente.

Los otros Typevalores son casos especiales. Por ejemplo, si el servicio utiliza una conexión D-Bus, entonces Type = dbuspodría ser la mejor opción. Se da systemdcuenta del hecho, y luego systemd rastreará este servicio (y todo lo que dependa de él) por la presencia de este servicio en el D-Bus.

Para usarlo Type = notify, el proceso debe poder conectarse al socket Unix especificado en la variable de entorno $NOTIFY_SOCKETe informar su estado escribiendo mensajes en ese socket cuando sea necesario. Además, el archivo de servicio debe especificar la NotifyAccessopción para otorgar acceso al socket de notificación según corresponda.

Hay una utilidad de línea de comandos systemd-notifyy una función de biblioteca C sd_notify(3)que puede usar para enviar estos mensajes, pero si ninguno de ellos es adecuado para sus requisitos, puede implementar su propio remitente de mensajes. Los mensajes requeridos son muy simples y parecen asignaciones de variables de shell: por ejemplo, para notificar que el servicio ha completado con éxito el inicio y está listo para atender cualquier solicitud entrante, el servicio debe enviar la cadena equivalente a la salida del printf "READY=1\n"socket. Consulte man 3 sd_notifypara obtener más detalles sobre los mensajes reconocidos.

Nota: muchas aplicaciones de servicio diseñadas para ser portátiles en muchos sistemas de estilo Unix pueden comportarse como b) de forma predeterminada, pero se puede hacer que funcionen como a) agregando una opción (generalmente descrita como "no bifurcar", "seguir ejecutándose" en primer plano "," no demonizar "o similar). En ese caso, si la opción no tiene otros efectos secundarios, sería preferible agregar la opción y usar el comportamiento tipo a) systemd.