The first public release of the Nitro project has been published, which develops a minimalist initialization system with process execution control features. The project is developed by Leah Neukirchen, one of the maintainers of packages in the Void Linux distribution. The code is written in C and is distributed under the 0BSD license.
Nitro can be used both as an init process (pid 1) and as an unprivileged process that oversees the seamless execution of applications in user space and restarts tasks in case of failures. It supports operation on Linux and FreeBSD, and can be used in environments based on the standard C library Musl. Areas of application include embedded systems, ramdisk images (initramfs), containers (Docker/Podman/LXC/Kubernetes), as well as workstations and server systems. To manage service operation and interaction with the init process, a command-line utility nitroctl is provided.
Instead of composite initialization scripts, Nitro implements a model based on extracting each function into a separate script. For each service in the hierarchy /etc/nitro, a subdirectory is created where the following scripts can reside: setup — contains commands executed before the service starts; run — defines the startup script for the service; finish — includes commands executed after the service finishes. For log management, a symbolic link named log is used, pointing to another service where the output will be redirected. To disable service auto-start, it is enough to create a file named 'down' in its directory, and to ignore the service, a '@' symbol should be added to the directory name.
The author of the project notes the following advantages of Nitro compared to other initialization systems:
- All state is stored in RAM, simplifying operations in environments with read-only disk partitions.
- Architecture based on event processing, which does not use polling.
- No memory allocation operations during runtime (all buffers are allocated at startup).
- Limited use of file descriptors during operation.
- Delivery in the form of a single self-contained executable file and a utility for system management.
- The absence of configuration compilation stages — the service's operation is determined by simple scripts in the service-related directory.
- The availability of a service restart function after a failure.
- The presence of a logging mechanism that can be enabled by default or selectively for specific services.
- The ability to build a log processing chain covering multiple services.
- Operation is not dependent on the accuracy of the system clock.
- Support for starting on FreeBSD via /etc/ttys.
- The ability to build as a compact statically compiled executable file using musl libc.
Source: opennet.ru
