Índice ∙ Directivas

Machine Translated by Google

desarrollo del sistema

Nombre

daemon — Demonios del sistema de escritura y empaquetado

Descripción
Un demonio es un proceso de servicio que se ejecuta en segundo plano y supervisa el sistema o proporciona funcionalidad a otros procesos. Tradicionalmente, los demonios se implementan siguiendo un esquema originado en SysV Unix.
Los demonios modernos deberían seguir un esquema más simple pero más poderoso (aquí llamados demonios de "nuevo estilo"), tal como lo implementa systemd(1). Esta página de manual cubre ambos esquemas y, en particular, incluye recomendaciones para demonios que se
incluirán en el sistema de inicio systemd.

Demonios SysV

Cuando se inicia un demonio SysV tradicional, debe ejecutar los siguientes pasos como parte de la inicialización. Tenga en cuenta que estos pasos son innecesarios para demonios de nuevo estilo (ver más abajo) y solo deben implementarse si la compatibilidad con SysV es esencial.

1. Cierre todos los descriptores de archivos abiertos excepto entrada, salida y error estándar (es decir, los primeros tres descriptores de archivos 0, 1, 2). Esto garantiza que ningún descriptor de archivo pasado accidentalmente permanezca en el proceso del demonio. En
Linux, esto se implementa mejor iterando a través de /proc/self/fd, con un respaldo de iteración desde el descriptor de archivo 3 hasta el valor devuelto por getrlimit() para RLIMIT_NOFILE.

2. Restablezca todos los controladores de señales a sus valores predeterminados. La mejor manera de hacerlo es iterar a través de las señales disponibles hasta el límite de _NSIG y restablecerlas a SIG_DFL.

3. Restablezca la máscara de señal usando sigprocmask().

4. Desinfecte el bloque de entorno, eliminando o restableciendo las variables de entorno que podrían afectar negativamente el tiempo de ejecución del demonio.

5. Llame a fork() para crear un proceso en segundo plano.

6. En el niño, llame a setsid() para desconectarse de cualquier terminal y crear una sesión independiente.

7. En el hijo, llame a fork() nuevamente para asegurarse de que el demonio nunca pueda volver a adquirir una terminal. (Esto es relevante si el programa, y todas sus dependencias, no especifican cuidadosamente `O_NOCTTY` en cada
y cada llamada `open()` que potencialmente podría abrir un nodo de dispositivo TTY).

8. Llame a exit() en el primer hijo, de modo que solo quede el segundo hijo (el proceso del demonio real). Esto garantiza que el proceso del demonio se vuelva a vincular a init/PID 1, como deberían ser todos los demonios.

9. En el proceso del demonio, conecte /dev/null a la entrada, salida y error estándar.

10. En el proceso del demonio, restablezca umask a 0, de modo que los modos de archivo pasados a open(), mkdir() y similares controlen directamente el modo de acceso de los archivos y directorios creados.

11. En el proceso del demonio, cambie el directorio actual al directorio raíz (/), para evitar que el demonio bloquee involuntariamente el desmontaje de los puntos de montaje.

12. En el proceso del demonio, escriba el PID del demonio (como lo devuelve getpid()) en un archivo PID, por ejemplo /run/[Link] (para un demonio hipotético "foobar") para garantizar que el demonio no pueda iniciarse más. más de una vez. Esto debe
implementarse sin carreras para que el archivo PID solo se actualice cuando se verifique al mismo tiempo que el PID previamente almacenado en el archivo PID ya no existe o pertenece a un proceso externo.

13. En el proceso del demonio, elimine los privilegios, si es posible y aplicable.

14. Desde el proceso del demonio, notifique al proceso original iniciado que la inicialización se ha completado. Esto se puede implementar a través de una tubería sin nombre o un canal de comunicación similar que se crea antes de la primera bifurcación() y, por lo tanto, está disponible tanto en el
proceso original como en el demonio.

15. Llame a exit() en el proceso original. El proceso que invocó al demonio debe poder confiar en que esta salida() ocurre después de que se completa la inicialización y se establecen todos los canales de comunicación externos.
y accesible.

La función BSD daemon() no debe usarse, ya que implementa solo un subconjunto de estos pasos.

Un demonio que necesite proporcionar compatibilidad con sistemas SysV debería implementar el esquema señalado anteriormente. Sin embargo, se recomienda hacer que este comportamiento sea opcional y configurable mediante un argumento de línea de comando para facilitar la depuración y
simplificar la integración en sistemas que utilizan systemd.

Demonios de nuevo estilo

Los servicios modernos para Linux deberían implementarse como demonios de nuevo estilo. Esto facilita su supervisión y control en tiempo de ejecución y simplifica su implementación.

Para desarrollar un demonio de nuevo estilo, no es necesario implementar ninguno de los pasos de inicialización recomendados para los demonios SysV. Los sistemas de inicio de nuevo estilo, como systemd, los hacen todos redundantes. Además, dado que algunos de estos pasos interfieren con el
monitoreo de procesos, la transferencia de descriptores de archivos y otras funciones del administrador de servicios, se recomienda no ejecutarlos cuando se ejecutan como un servicio de nuevo estilo.

Tenga en cuenta que los sistemas de inicio de nuevo estilo garantizan la ejecución de procesos demonio en un contexto de proceso limpio: se garantiza que el bloque de entorno esté desinfectado, que los manejadores de señales y la máscara se restablezcan y que no se pasen descriptores de
archivos sobrantes. Los demonios se ejecutarán en su propia sesión, con la entrada estándar conectada a /dev/null y la salida estándar/error conectada a systemd­[Link](8) servicio de registro, a menos que se configure lo contrario. La umask se restablece.

Se recomienda que los demonios de nuevo estilo implementen lo siguiente:

1. Si corresponde, el demonio debe notificar al administrador de servicios sobre la finalización del inicio o las actualizaciones de estado a través de sd_notify(3). interfaz, en particular READY=1 y STATUS=….

2. Si se recibe SIGTERM , cierre el demonio y salga limpiamente. Se debe enviar una notificación STOPPING=1 a través de sd_notify(3).

3. Si se recibe SIGHUP , vuelva a cargar los archivos de configuración, si corresponde. Esto debe combinarse con notificaciones vía sd_notify(3): RECARGANDO=1 y LISTO=1.

4. Proporcione un código de salida correcto del proceso del demonio principal, ya que lo utiliza el administrador de servicios para detectar errores y problemas del servicio. Se recomienda seguir el esquema del código de salida definido en la LSB.
recomendaciones para scripts de inicio de SysV.

5. Si es posible y aplicable, exponga la interfaz de control del demonio a través del sistema D­Bus IPC y tome un nombre de bus como último paso de la inicialización.

6. Para la integración en systemd, proporcione un archivo de unidad .service que contenga información sobre cómo iniciar, detener y mantener el demonio. Ver [Link](5) para más detalles.

7. En la medida de lo posible, confíe en la funcionalidad del administrador de servicios para limitar el acceso del demonio a archivos, servicios y otros recursos; es decir, en el caso de systemd, confíe en el control de límite de recursos de systemd.
de implementar el suyo propio, confíe en el código de eliminación de privilegios de systemd en lugar de implementarlo en el demonio, y así sucesivamente. Ver [Link](5) para los controles disponibles.

8. Si se utiliza D­Bus, haga que su daemon bus sea activable proporcionando un archivo de configuración de activación del servicio D­Bus. Esto tiene múltiples ventajas: su demonio puede iniciarse de forma diferida bajo demanda; puede iniciarse en paralelo
con otros demonios que lo requieran, lo que maximiza la paralelización y la velocidad de arranque; su demonio se puede reiniciar en caso de falla sin perder ninguna solicitud de bus, ya que el bus pone en cola solicitudes de servicios activables. Consulte
a continuación para obtener más detalles.

9. Si su demonio proporciona servicios a otros procesos locales o clientes remotos a través de un socket, debe activarse mediante socket siguiendo el esquema que se indica a continuación. Al igual que la activación D­Bus, esto permite
demanda de inicio de servicios así como permite una mejor paralelización del inicio de servicios. Además, para protocolos sin estado (como syslog, DNS), un demonio que implementa activación basada en sockets se puede reiniciar sin perder una sola solicitud. Consulte a continuación para
obtener más detalles.

10. Si el servicio abre sockets u otros archivos por sí solo, y esos descriptores de archivos sobreviven a un reinicio, el demonio debe almacenarlos en el administrador de servicios a través de sd_notify(3). con FDSTORE=1.

11. En lugar de utilizar la llamada syslog() para iniciar sesión directamente en el servicio syslog del sistema, un demonio de nuevo estilo puede optar por simplemente iniciar sesión en el error estándar mediante fprintf(), que luego se reenvía a syslog. Si los niveles de registro son necesarios, estos
se pueden codificar prefijando líneas de registro individuales con cadenas como "<4>" (para el nivel de registro 4 "WARNING" en el esquema de prioridad de syslog), siguiendo un estilo similar al nivel printk() del kernel de Linux. sistema. Para más detalles, consulte sd­daemon(3) y [Link](5).

12. Como los demonios de nuevo estilo se invocan sin un TTY controlador (sino como sus propios líderes de sesión), se debe tener cuidado de especificar siempre O_NOCTTY en open(2) llamadas que posiblemente hagan referencia a un nodo de dispositivo TTY, de modo que no se adquiera
accidentalmente ningún TTY de control.

Estas recomendaciones son similares, pero no idénticas, a los requisitos de Apple MacOS X Daemon.

Activación

Los sistemas de inicio de nuevo estilo proporcionan múltiples mecanismos adicionales para activar servicios, como se detalla a continuación. Es común que los servicios estén configurados para activarse mediante más de un mecanismo al mismo tiempo. Un ejemplo para systemd: [Link]
puede activarse cuando se conecta el hardware Bluetooth o cuando una aplicación accede a sus interfaces de programación a través de D­Bus. O bien, un demonio del servidor de impresión podría activarse cuando el tráfico llegue a un puerto IPP, cuando se conecte una impresora o cuando un archivo
esté en cola en el directorio de cola de impresión. Incluso para los servicios que están destinados a iniciarse incondicionalmente al iniciar el sistema, es una buena idea implementar algunos de los diversos esquemas de activación que se describen a continuación para maximizar la paralelización. Si un
demonio implementa un servicio D­Bus o un socket de escucha, implementar el esquema completo de activación de bus y socket permite iniciar el demonio con sus clientes en paralelo (lo que acelera el arranque), dado que todos sus canales de comunicación ya están establecidos, y no se pierde
ninguna solicitud porque las solicitudes de los clientes serán puestas en cola por el sistema de bus (en el caso de D­Bus) o el kernel (en el caso de sockets) hasta que se complete la activación.

Activación al arrancar

Los demonios de estilo antiguo generalmente se activan exclusivamente en el arranque (y manualmente por el administrador) a través de scripts de inicio SysV, como se detalla en la Especificación básica básica estándar de LSB Linux. Este método de activación es compatible de forma
omnipresente en los sistemas de inicio de Linux, tanto en los sistemas antiguos como en los nuevos. Entre otras cuestiones, los scripts de inicio de SysV tienen la desventaja de involucrar scripts de shell en el proceso de arranque. Los sistemas de inicio de nuevo estilo generalmente usan versiones
actualizadas de activación, tanto durante el arranque como durante el tiempo de ejecución, y usan archivos de descripción de servicios más mínimos.

En systemd, si el desarrollador o administrador quiere asegurarse de que un servicio u otra unidad se active automáticamente al arrancar, se recomienda colocar un enlace simbólico al archivo de la unidad en el directorio .wants/ de multi­[Link] o gráfico. .target, que normalmente se utilizan como
destinos de arranque al iniciar el sistema. Ver [Link](5) para obtener detalles sobre los directorios .wants/ y [Link](7) para obtener detalles sobre los dos destinos de arranque.

Activación basada en sockets

Para maximizar la posible paralelización y robustez y simplificar la configuración y el desarrollo, se recomienda que todos los demonios de nuevo estilo que se comunican a través de sockets de escucha utilicen activación basada en sockets. En un esquema de activación basado en sockets, la creación
y vinculación del socket de escucha como canal de comunicación principal de los demonios con los clientes locales (y a veces remotos) se traslada del código del demonio al administrador de servicios. Según la configuración por demonio, el administrador de servicios instala los sockets y luego los entrega
al proceso generado tan pronto como se inicia el demonio respectivo. Opcionalmente, la activación del servicio se puede retrasar hasta que llegue el primer tráfico entrante al socket para implementar la activación de demonios bajo demanda. Sin embargo, la principal ventaja de este esquema es que
todos los proveedores y todos los consumidores de los sockets pueden iniciarse en paralelo tan pronto como se establezcan todos los sockets. Además de eso, los demonios se pueden reiniciar perdiendo solo una cantidad mínima de transacciones de clientes, o incluso cualquier solicitud de cliente
(esto último es particularmente cierto para protocolos sin estado, como DNS o syslog), porque el socket permanece vinculado. y accesible durante el reinicio, y todas las solicitudes se ponen en cola mientras el demonio no puede procesarlas.

Los demonios de nuevo estilo que admiten la activación de sockets deben poder recibir sus sockets del administrador de servicios en lugar de crearlos y vincularlos ellos mismos. Para obtener detalles sobre las interfaces de programación para este esquema proporcionadas por systemd, consulte
sd_listen_fds(3) y sd­daemon(3). Para obtener detalles sobre cómo portar demonios existentes a una activación basada en sockets, consulte a continuación. Con un mínimo esfuerzo, es posible implementar la activación basada en sockets además de la creación de sockets internos tradicionales en
la misma base de código para admitir sistemas de inicio tanto nuevos como antiguos desde el mismo demonio binario.

systemd implementa la activación basada en sockets a través de unidades .socket , que se describen en [Link](5). Al configurar unidades de socket para activación basada en sockets, es esencial que todos los sockets de escucha sean conectados por la unidad de destino especial [Link].
Se recomienda colocar una directiva WantedBy=[Link] en la sección [Instalar] para agregar automáticamente dicha dependencia en la instalación de una unidad de enchufe. A menos que se establezca DefaultDependencies=no , las dependencias de orden necesarias se crean implícitamente
para todas las unidades de socket. Para obtener más información sobre [Link], consulte [Link](7). No es necesario ni recomendado colocar dependencias adicionales en unidades de socket (por ejemplo, de multi­[Link] o similares) cuando se instala una en
[Link].

Activación basada en bus

Cuando se utiliza el sistema D­Bus IPC para comunicarse con clientes, los demonios de nuevo estilo deben usar activación de bus para que se activen automáticamente cuando una aplicación cliente acceda a sus interfaces IPC. Esto se configura en los archivos de servicio D­Bus (¡no debe confundirse
con los archivos de la unidad de servicio systemd!). Para garantizar que D­Bus utilice systemd para iniciar y mantener el demonio, utilice la directiva SystemdService= en estos archivos de servicio para configurar el servicio systemd correspondiente para un servicio D­Bus. por ejemplo: para un servicio D­
Bus cuyo archivo de activación D­Bus se denomina [Link], asegúrese de configurar SystemdService=rtkit­[Link] en ese archivo para vincularlo al servicio systemd rtkit­[Link] . Esto es necesario para garantizar que el demonio se inicie sin carreras
cuando se activa a través de múltiples mecanismos simultáneamente.

Activación basada en dispositivo

A menudo, los demonios que administran un tipo particular de hardware deben activarse sólo cuando el hardware del tipo respectivo esté conectado o esté disponible de otra manera. En un sistema de inicio de nuevo estilo, es posible vincular la activación a eventos de conexión/desconexión de
hardware. En systemd, los dispositivos del kernel que aparecen en el árbol de dispositivos sysfs/udev pueden exponerse como unidades si están etiquetados con la cadena "systemd". Como cualquier otro tipo de unidad, pueden luego incorporar otras unidades cuando se activan (es decir, se conectan) y
así implementar la activación basada en dispositivos. Las dependencias de systemd se pueden codificar en la base de datos udev a través de la propiedad SYSTEMD_WANTS= . Ver [Link](5) para más detalles. A menudo, es mejor obtener servicios de los dispositivos sólo
indirectamente a través de objetivos dedicados. Ejemplo: en lugar de extraer [Link] de todos los diversos dongles bluetooth y otro hardware disponible, extraiga [Link] de ellos y [Link] de ese destino. Esto proporciona una mejor abstracción y brinda a los administradores
la opción de habilitar [Link] controlando un enlace simbólico [Link]/ de manera uniforme con un comando como enable of systemctl(1). en lugar de manipular el conjunto de reglas de udev.

Activación basada en ruta

A menudo, el tiempo de ejecución de los demonios que procesan archivos o directorios spool (como un sistema de impresión) puede retrasarse hasta que estos objetos del sistema de archivos cambien de estado o dejen de estar vacíos. Los sistemas de inicio de nuevo estilo proporcionan una forma
de vincular la activación del servicio a los cambios del sistema de archivos. systemd implementa este esquema mediante activación basada en ruta configurada en unidades .path , como se describe en [Link](5).

Activación basada en temporizador

Algunos demonios que implementan trabajos de limpieza que deben ejecutarse en intervalos regulares se benefician de la activación basada en temporizador. En systemd, esto se implementa mediante unidades .timer , como se describe en [Link](5).

Otras formas de activación

Se han sugerido e implementado otras formas de activación en algunos sistemas. Sin embargo, a menudo existen alternativas más simples o mejores, o se pueden crear combinaciones de los esquemas anteriores. Ejemplo: a veces, parece útil iniciar demonios o unidades .socket cuando se configura
una dirección IP específica en una interfaz de red, porque los sockets de red estarán vinculados a la dirección. Sin embargo, una alternativa para implementar esto es utilizar la opción de socket IP_FREEBIND/IPV6_FREEBIND de Linux, a la que se puede acceder a través de FreeBind=yes en
los archivos de socket de systemd (consulte [Link](5) para más detalles). Esta opción, cuando está habilitada, permite que los sockets se vinculen a una dirección IP no local y no configurada y, por lo tanto, permite vinculaciones a una dirección IP particular antes de que esté realmente
disponible, lo que hace que dicha dependencia explícita de la dirección configurada sea redundante. Otro desencadenante que se sugiere a menudo para la activación del servicio es la baja carga del sistema. Sin embargo, también en este caso un enfoque más convincente podría ser hacer un uso
adecuado de las funciones del sistema operativo, en particular, la CPU o el programador de E/S de Linux. En lugar de programar trabajos desde el espacio de usuario basándose en la supervisión del programador del sistema operativo, es recomendable dejar la programación de procesos al propio
programador del sistema operativo. systemd proporciona acceso detallado a la CPU y a los programadores de E/S. Si un proceso ejecutado por el administrador de servicios no afectará negativamente la cantidad de CPU o ancho de banda de E/S disponible para otros procesos, debe configurarse
con CPUSchedulingPolicy=idle y/o IOSchedulingClass=idle. Opcionalmente, esto se puede combinar con la activación basada en temporizador para programar trabajos en segundo plano durante el tiempo de ejecución y con un impacto mínimo en el sistema, y eliminarlos de la fase de inicio.

Integración con systemd

Escribir archivos de unidad systemd

Al escribir archivos de unidades systemd, se recomienda considerar las siguientes sugerencias:

1. Si es posible, no utilice la configuración Tipo=bifurcación en archivos de servicio. Pero si lo hace, asegúrese de configurar la ruta del archivo PID usando PIDFile=. Ver [Link](5) para más detalles.

2. Si su demonio registra un nombre D­Bus en el bus, asegúrese de usar Type=dbus en el archivo de servicio si es posible.

3. Asegúrese de establecer una cadena de descripción legible por humanos con Descripción=.

4. No desactive DefaultDependencies=, a menos que realmente sepa lo que hace y su unidad esté involucrada en un arranque temprano o un apagado tardío del sistema.

5. Normalmente, pocas dependencias, si es que hay alguna, deberían definirse explícitamente. Sin embargo, si configura dependencias explícitas, consulte únicamente los nombres de las unidades que figuran en [Link](7) o nombres introducidos por su
propio paquete para mantener el archivo de la unidad independiente del sistema operativo.

6. Asegúrese de incluir una sección [Instalar] que incluya información de instalación para el archivo de la unidad. Ver [Link](5) para más detalles. Para activar su servicio en el arranque, asegúrese de agregar una directiva WantedBy=multi­[Link] o WantedBy=[Link] . Para activar
su socket en el arranque, asegúrese de agregar WantedBy=[Link]. Por lo general, también desea asegurarse de que cuando se instale su servicio, su socket también esté instalado, por lo tanto, agregue Also=[Link] en su archivo de servicio [Link], para un programa
hipotético foo.

Instalación de archivos de servicio systemd

En el momento de la instalación de la compilación (por ejemplo, make install durante la compilación del paquete), se recomienda que los paquetes instalen sus archivos de unidad systemd en el directorio devuelto por pkg­config systemd ­­variable=systemdsystemunitdir (para servicios del sistema) o pkg­
config systemd ­­variable =systemduserunitdir (para servicios de usuario). Esto hará que los servicios estén disponibles en el sistema a pedido explícito, pero no los activará automáticamente durante el inicio.
Opcionalmente, durante la instalación del paquete (por ejemplo, rpm ­i por parte del administrador), se deben crear enlaces simbólicos en los directorios de configuración de systemd mediante el comando enable de systemctl(1). herramienta para activarlos automáticamente en el arranque.

Paquetes que usan autoconf(1) Se recomienda utilizar un extracto del script de configuración como el siguiente para determinar la ruta de instalación de la unidad durante la configuración de origen:

PKG_PROG_PKG_CONFIG()
AC_ARG_WITH([systemdsystemunitdir],
[AS_HELP_STRING([­­with­systemdsystemunitdir=DIR], [Directorio de archivos de servicio systemd])],, [with_systemdsystemunitdir=auto])

AS_IF([test "x$with_systemdsystemunitdir" = "xyes" ­o "x$with_systemdsystemunitdir" = "xauto"], [ def_systemdsystemunitdir=$($PKG_CONFIG ­­

variable=systemdsystemunitdir systemd)

AS_IF([prueba "x$def_systemdsystemunitdir" = "x"],

[AS_IF([prueba "x$with_systemdsystemunitdir" = "xyes"],
[AC_MSG_ERROR([se solicitó soporte para systemd pero pkg­config no puede consultar el paquete systemd])]) with_systemdsystemunitdir=no],

[with_systemdsystemunitdir="$def_systemdsystemunitdir"])])
AS_IF([prueba "x$with_systemdsystemunitdir" != "xno"],
[AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])])
AM_CONDITIONAL([HAVE_SYSTEMD], [prueba "x$with_systemdsystemunitdir"! = "xno"])

Este fragmento permite la instalación automática de los archivos de la unidad en máquinas con systemd y, opcionalmente, permite su instalación incluso en máquinas que carecen de systemd. (La modificación de este fragmento para el directorio de la unidad de usuario se deja como ejercicio para el lector).

Además, para garantizar que make distcheck siga funcionando, se recomienda agregar lo siguiente al archivo [Link] de nivel superior en el sistema basado en automake(1). proyectos:

AM_DISTCHECK_CONFIGURE_FLAGS = \
­­with­systemdsystemunitdir=$$dc_install_base/$(systemdsystemunitdir)

Finalmente, los archivos unitarios deben instalarse en el sistema con un extracto de automake como el siguiente:

si HAVE_SYSTEMD
systemdsystemunit_DATA = \ [Link] \
[Link]

endif

En las revoluciones(8) .spec , utilice fragmentos como los siguientes para habilitar/deshabilitar el servicio durante la instalación/desinstalación. Esto hace uso de las macros RPM enviadas junto con systemd. Consulte las pautas de embalaje de su distribución para obtener detalles y el equivalente para
otros administradores de paquetes.

En la parte superior del archivo:

BuildRequires: systemd %{?

systemd_requires}

Y a modo de scriptlets, más abajo:

%post
%systemd_post [Link] [Link]

%preun
%systemd_preun [Link] [Link]

%postun
%systemd_postun

Si el servicio se reiniciará durante las actualizaciones, reemplace el scriptlet "%postun" anterior con lo siguiente:

%postun
%systemd_postun_with_restart [Link]

Tenga en cuenta que "%systemd_post" y "%systemd_preun" esperan los nombres de todas las unidades que se instalan/eliminan como argumentos, separados por espacios. "%systemd_postun" no espera argumentos. "%systemd_postun_with_restart" espera
que las unidades se reinicien como argumentos.

Para facilitar las actualizaciones desde una versión de paquete que incluye solo scripts de inicio SysV a una versión de paquete que incluye un script de inicio SysV y un archivo de servicio systemd nativo, utilice un fragmento como el siguiente:

%triggerun ­­foobar < 0.47.11­1 if /sbin/chkconfig

­­nivel 5 foobar; entonces
/bin/systemctl ­­no­reload enable [Link] [Link] >/dev/null 2>&1 || : fi

Donde 0.47.11­1 es la primera versión del paquete que incluye el archivo de unidad nativo. Este fragmento garantizará que la primera vez que se instale el archivo de la unidad, se habilitará si y solo si el script de inicio SysV está habilitado, asegurando
así que el estado de habilitación no cambie. Tenga en cuenta que chkconfig es un comando específico de Fedora que puede usarse para verificar si un script de inicio SysV está habilitado. Otros sistemas operativos tendrán que utilizar comandos
diferentes aquí.

Portando demonios existentes

Dado que los sistemas de inicio de nuevo estilo, como systemd, son compatibles con los sistemas de inicio SysV tradicionales, no es estrictamente necesario migrar los demonios existentes al nuevo estilo. Sin embargo, hacerlo ofrece funcionalidad adicional a los demonios, además de simplificar la
integración en sistemas de inicio de nuevo estilo.

Para portar un demonio compatible con SysV existente, se recomiendan los siguientes pasos:

1. Si aún no está implementado, agregue un modificador de línea de comando opcional al demonio para deshabilitar la demonización. Esto es útil no sólo para usar el demonio en sistemas de inicio de nuevo estilo, sino también para facilitar la depuración.

2. Si el demonio ofrece interfaces con otro software que se ejecuta en el sistema local a través de sockets AF_UNIX locales , considere implementar la activación basada en sockets (ver arriba). Generalmente, un parche mínimo es suficiente para
implemente esto: extienda la creación de socket en el código del demonio para que sd_listen_fds(3) Se comprueba primero si hay sockets ya pasados. Si se pasan sockets (es decir, cuando sd_listen_fds() devuelve un valor positivo), omita el paso de creación del socket y use los sockets pasados.
En segundo lugar, asegúrese de que los nodos de socket del sistema de archivos para los sockets AF_UNIX locales utilizados en la activación basada en sockets no se eliminen cuando se cierre el demonio, si se han pasado sockets. En tercer lugar, si el demonio normalmente cierra todos los
descriptores de archivos abiertos restantes como parte de su inicialización, los sockets pasados desde el administrador de servicios deben conservarse. Dado que los sistemas de inicio de nuevo estilo garantizan que no se pasen descriptores de archivos sobrantes a los procesos ejecutados,
podría ser una buena opción simplemente omitir el cierre de todos los descriptores de archivos abiertos restantes si se pasan sockets.

3. Escriba e instale un archivo de unidad systemd para el servicio (y los sockets si se utiliza activación basada en sockets, así como un archivo de unidad de ruta, si el demonio procesa un directorio de spool), consulte más arriba para obtener más detalles.
 4. Si el demonio expone interfaces a través de D­Bus, escriba e instale un archivo de activación de D­Bus para el servicio; consulte más arriba para obtener más detalles.

Machine Translated by Google

Colocar datos de demonio

Se recomienda seguir las pautas generales para colocar archivos de paquetes, como se explica en jerarquía de archivos(7).

Ver también

sistemad(1), sd­daemon(3), sd_listen_fds(3), sd_notificar(3), demonio(3), [Link](5), jerarquía de archivos (7)