Se ha publicado el primer lanzamiento público del proyecto Nitro, que desarrolla un sistema de inicialización minimalista con funciones de control de la ejecución de procesos. El proyecto es desarrollado por Leah Neukirchen, uno de los mantenedores de paquetes en la distribución Void Linux. El código está escrito en C y se distribuye bajo la licencia 0BSD.
Nitro puede ser utilizado tanto como proceso init (pid 1) como en forma de proceso no privilegiado, controlando la ejecución continua de aplicaciones en el espacio del usuario y reiniciando tareas en caso de fallos. Se admite el funcionamiento en Linux y FreeBSD, y es posible su uso en entornos basados en la biblioteca estándar de C Musl. Se mencionan como áreas de aplicación sistemas embebidos, imágenes de discos RAM (initramfs), contenedores (Docker/Podman/LXC/Kubernetes), así como estaciones de trabajo y sistemas de servidores. Se proporciona una utilidad de línea de comandos, nitroctl, para gestionar el funcionamiento de los servicios e interactuar con el proceso init.
En lugar de scripts de inicialización compuestos, Nitro utiliza un modelo basado en mover cada función a un script separado. Para cada servicio en la jerarquía /etc/nitro se crea un subdirectorio donde pueden colocarse los siguientes scripts: setup — contiene comandos que se ejecutan antes de iniciar el servicio; run — define el script de inicio del servicio; finish — incluye comandos que se ejecutan después de que el servicio haya terminado. Para organizar la gestión de registros, se utiliza un enlace simbólico llamado log, que apunta a otro servicio al que se redirigirá la salida. Para deshabilitar el inicio automático de un servicio, basta con crear un archivo llamado 'down' en su directorio, y para ignorar el servicio, se debe agregar el símbolo '@' al nombre del directorio.
El autor del proyecto señala las siguientes ventajas de Nitro en comparación con otros sistemas de inicialización:
- Todo el estado se almacena en la RAM, lo que simplifica el trabajo en entornos con particiones de disco en modo solo lectura.
- Arquitectura basada en el procesamiento de eventos, sin utilizar sondas en modo polling.
- No hay operaciones de asignación de memoria durante la ejecución (todos los búferes se asignan al inicio).
- Uso limitado de descriptores de archivos durante la operación.
- Se entrega en forma de un solo archivo ejecutable independiente y una utilidad para gestionar el sistema.
- La ausencia de etapas de compilación de la configuración — el funcionamiento del servicio está determinado por scripts simples en el directorio asociado al servicio.
- Disponibilidad de la función para reiniciar servicios tras un fallo.
- Presencia de un mecanismo de registro que se puede activar por defecto o selectivamente para servicios individuales.
- Capacidad de construir una cadena de procesamiento de logs que abarque múltiples servicios.
- El funcionamiento no depende de la precisión de la configuración del reloj del sistema.
- Soporte para iniciar en FreeBSD a través de /etc/ttys.
- Posibilidad de compilar en forma de un ejecutable miniatura estáticamente vinculado al usar musl libc.
Fuente: opennet.ru
