La première version publique du projet Nitro a été publiée. Il développe un système d'initialisation minimaliste avec des fonctions de contrôle de l'exécution des processus. Le projet est dirigé par Leah Neukirchen, l'une des personnes en charge des paquets dans la distribution Void Linux. Le code est écrit en C et distribué sous la licence 0BSD.
Nitro peut être utilisé à la fois comme processus d'init (pid 1) et sous la forme d'un processus non privilégié, contrôlant l'exécution ininterrompue des applications dans l'espace utilisateur et redémarrant des tâches en cas d'échecs. Il fonctionne sous Linux et FreeBSD, et peut être utilisé dans des environnements basés sur la bibliothèque standard C Musl. Les domaines d'application incluent les systèmes embarqués, les images de ram-disques (initramfs), les conteneurs (Docker/Podman/LXC/Kubernetes), ainsi que les stations de travail et les systèmes serveurs. Pour gérer les services et interagir avec le processus d'init, un utilitaire en ligne de commande, nitroctl, est fourni.
Au lieu de scripts d'initialisation composés, Nitro utilise un modèle basé sur le fait de déplacer chaque fonction dans un script séparé. Pour chaque service dans la hiérarchie /etc/nitro, un sous-dossier est créé, où les scripts suivants peuvent être placés : setup — contient les commandes exécutées avant le démarrage du service ; run — définit le scénario de démarrage du service ; finish — inclut les commandes exécutées après l'achèvement du service. Pour organiser la journalisation, un lien symbolique nommé log pointe vers un autre service, auquel la sortie sera redirigée. Pour désactiver le démarrage automatique d'un service, il suffit de créer un fichier nommé « down » dans son répertoire, et pour ignorer un service, il faut ajouter le symbole « @ » au nom du répertoire.
L'auteur du projet souligne les avantages suivants de Nitro par rapport à d'autres systèmes d'initialisation :
- Tout l'état est conservé en RAM, ce qui simplifie le fonctionnement dans des environnements avec des partitions en mode lecture seule.
- Architecture basée sur le traitement des événements, n'utilisant pas de sondage (polling).
- Absence d'opérations d'allocation de mémoire pendant l'exécution (tous les tampons sont alloués au démarrage).
- Utilisation limitée des descripteurs de fichiers pendant l'exécution.
- Livré sous la forme d'un seul exécutable autonome et d'un utilitaire pour gérer le système.
- L'absence d'étapes de compilation de configuration - le fonctionnement du service est déterminé par des scripts simples dans le répertoire associé au service.
- Présence d'une fonction de redémarrage des services après un échec.
- Présence d'un mécanisme de journalisation, pouvant être activé par défaut ou de manière sélective pour des services spécifiques.
- Possibilité de construire une chaîne de traitement des journaux couvrant plusieurs services.
- Le fonctionnement ne dépend pas de la précision des horloges système.
- Support du démarrage sous FreeBSD via /etc/ttys.
- Possibilité de compilation sous la forme d'un fichier exécutable statiquement compilé en miniature en utilisant musl libc.
Source : opennet.ru
