Ignora esta página wiki de Arch.

Question

Quiero escribir mis propios systemdarchivos unitarios para administrar comandos ¹ de ejecución realmente larga (en el orden de horas). mientras mira elArtículo de ArchWiki sobre systemd, dice lo siguiente con respecto a elegir un tipo de inicio:

Type=simple(predeterminado): systemd considera que el servicio se inicia inmediatamente.El proceso no debe bifurcarse.. No utilice este tipo si es necesario solicitar otros servicios en este servicio, a menos que esté activado por socket.

¿Por qué el proceso no debe bifurcarse en absoluto? ¿Se refiere a una bifurcación al estilo del proceso de invocación del demonio (el padre se bifurca, luego sale), o cualquier tipo de bifurcación?

---

¹ No quiero tmux/screen porque quiero una forma más elegante de verificar el estado y reiniciar el servicio sin recurrir a tmux send-keys.

Answer 1

El servicio puede realizar la forkllamada al sistema. Systemd no lo evitará, ni siquiera se dará cuenta si lo hace. Esta oración se refiere específicamente a la práctica de bifurcar al comienzo de un demonio para aislarlo de su proceso padre. "El proceso no debe bifurcarse [y salir del padre mientras se ejecuta el servicio en un proceso hijo]".

Elpágina de manualexplica esto de manera más detallada y con una redacción que no lleve a esta confusión particular.

Muchos programas que están destinados a ser utilizados como demonios tienen un modo (a menudo el modo predeterminado) en el que, cuando se inician, se aíslan de su padre. El demonio se inicia, llama fork()y el padre sale. El proceso hijo llama setsid()para ejecutarse en su propio grupo de procesos y sesión, y ejecuta el servicio. El propósito es que si el demonio se invoca desde una línea de comando del shell, el demonio no recibirá ninguna señal del kernel o del shell incluso si algo le sucede al terminal, como el cierre del terminal (en cuyo caso el shell envía SIGHUP a todos los grupos de procesos que conoce). Esto también hace que init adopte el proceso de servicio, que lo cosechará cuando salga, evitando unazombisi el demonio fue iniciado por algo que no wait()lo haría (esto no sucedería si el demonio fue iniciado por un shell).

Cuando un proceso de monitoreo como systemd inicia un demonio, la bifurcación es contraproducente. Se supone que el proceso de monitoreo reinicia el servicio si falla, por lo que necesita saber si el servicio sale, y eso es difícil si el servicio no es un hijo directo del proceso de monitoreo. Se supone que el proceso de monitoreo nunca muere y no tiene una terminal de control, por lo que no hay preocupaciones sobre señales no deseadas o cosechas. Por lo tanto, no hay ninguna razón para que el proceso de servicio no sea hijo del monitor, y hay una buena razón para que lo sea.

Answer 2

Ignora esta página wiki de Arch.

Se ha equivocado bastante con respecto a la Typeambientación. Además , esto no se limita solo a sus descripciones simple. Lo que dice forkingtambién está mal.

Las recomendaciones correctas para este tipo de cosas han existido durante décadas más que el propio systemd, y se remontan al menos a principios de la década de 1990. Como señalé enhttps://unix.stackexchange.com/a/476608/5132, en el documento systemd hay una versión recién llegada de las recomendaciones para demonios que repite en gran medida lo que los usuarios de demonios, IBM, las personas que usan inittaby... bueno... he estado diciendo durante décadas. (Ya era una respuesta frecuente cuando la escribí como tal en 2001.)

Repetir:

Si su programa tiene algún mecanismo de "daimonización", que en particular bifurca a un niño y sale del proceso padre,apágaloyNo lo uses. Gracias a daemontools et al. donde esto ha sido un requisito durante mucho tiempo, muchos programas han aumentado la capacidad deno tengotales mecanismos en los últimos 20 años, y otros simplemente no "endemoniazan" por defecto en primer lugar, por lo que pueden usarse en sus modos operativos predeterminados.

Los subsistemas de gestión de servicios lanzan procesos de servicio.ya en el contexto demoniaco. Esos procesos no necesitan "endemoniarse". (De hecho, en muchos sistemas operativos modernos es una falacia pensar que los programas inclusopoder"daæmonize" desde el contexto de una sesión de inicio de sesión, que es de lo que realmente se trata la "dæmonization".) Ya tienen los valores de entorno y los descriptores de archivos abiertos, apropiados para el contexto del dæmon, y las diversas cosas que de hecho hace la "dæmonization"frustraralgunas de las cosas convencionales que los administradores de servicios hacen regularmente con demonios (por ejemplo, capturar sus salidas/errores estándar en un registro).

Prefiere Type=simple, con apertura temprana de sockets (donde la administración del servicio abre sockets del servidor y los pasa como descriptores de archivos ya abiertos al programa de servicio), o Type=notify.

• Type=simpletrata el servicio como listo (para que los servicios solicitados en él puedan iniciarse o detenerse) tan pronto como comienza el proceso del servicio, con una apertura temprana del socket que emplea semántica de conexión de socket para retrasar a los clientes del servicio, en los puntos en los que intentan conectarse a los servidores para servicio, hasta que los servidores estén realmente listos.
• Type=notifytiene la desventaja de ser peculiar de systemd y Linux (junto con los problemas de no ser funcional en procesos de corta duración como el generación de shell systemd-notify, y de emplear el análisis de formas legibles por humanos a formas legibles por máquinas en un proceso privilegiado, donde los problemas del analizador tienenya pasóen el pasado) pero tiene la ventaja de proporcionar un control más preciso (desde el punto de vista del programa de servicio) de cuándo se considera que el servicio está realmente listo. También permite cierta personalización de la salida de estado.

Los programas de servicio, de ambos tipos, pueden bifurcarse. esta bifurcandoy luego salir del proceso originalese es el problema.

(Cabe señalar que esto es un problema tanto para ejecutar programas desde shells como para ejecutar programas desde administradores de servicios, ya que los usuarios ven que los programas terminan y provocan otro mensaje de shell casi de inmediato. De hecho, hoy mismo alguien preguntaba, una vez más , sobre la ejecución de programas desde el shell que se bifurcan y salen del padre, en¿Por qué a veces cuando ejecuto un programa en la terminal, no se ejecuta en la terminal?.)

Type=oneshotProbablemente no sea lo que desea en este caso particular, ya que el servicio se considera listo sólo cuando todo el programa de servicio se ha ejecutado hasta su finalización. Tiene sus usos, pero por lo que parece no se aplican a ti.

Nunca usar Type=forking. Debería ser un último recurso de desesperación, ya que casi ningún programarealmente habla el protocolo. Ellos están haciendoalgo más, que de hecho esnoeste protocolo, no es interoperable correctamente con este protocolo y, de hecho, no indica preparación.

Otras lecturas

• Jonathan de Boyne Pollard (2001). Errores a evitar al diseñar programas demonio Unix. Respuestas dadas con frecuencia.
• Jonathan de Boyne Pollard (2015).Realmente no necesitas demonizar. En realidad.. La Casa del Terror systemd.
• Jonathan de Boyne Pollard (2015).Problemas de protocolo de preparación con demonios de Unix. Respuestas dadas con frecuencia.
• https://unix.stackexchange.com/a/401611/5132