Pubblicata la prima edizione pubblica del progetto Nitro, che sviluppa un sistema di inizializzazione minimalista con funzioni di controllo sull'esecuzione dei processi. Il progetto è guidato da Leah Neukirchen, uno degli sviluppatori dei pacchetti nel distribuito Void Linux. Il codice è scritto in C e distribuito con licenza 0BSD.
Nitro può essere utilizzato sia come processo init (pid 1) sia come processo non privilegiato, che controlla l'esecuzione continua delle applicazioni nello spazio utente e riavvia i compiti in caso di guasti. È supportato su Linux e FreeBSD, con possibilità di utilizzo in ambienti basati sulla libreria standard C Musl. I casi d'uso includono sistemi embedded, immagini ram-disk (initramfs), contenitori (Docker/Podman/LXC/Kubernetes), nonché workstation e sistemi server. Per gestire il funzionamento dei servizi e interagire con il processo init, è fornuto uno strumento da riga di comando chiamato nitroctl.
Invece di script di inizializzazione complessi, Nitro adotta un modello che prevede l'estrazione di ogni funzione in uno script separato. Per ogni servizio nella gerarchia /etc/nitro viene creato un sottodirectory, all'interno della quale possono essere collocati i seguenti script: setup — contiene i comandi eseguiti prima dell'avvio del servizio; run — definisce lo scenario di avvio del servizio; finish — include i comandi eseguiti dopo il completamento del servizio. Per organizzare la registrazione dei log, viene utilizzato un collegamento simbolico chiamato log, che punta a un altro servizio, a cui verrà reindirizzato l'output. Per disabilitare l'avvio automatico del servizio, è sufficiente creare un file chiamato “down” nella sua directory, mentre per ignorare il servizio si deve aggiungere il simbolo “@” al nome della directory.
L'autore del progetto sottolinea i seguenti vantaggi di Nitro rispetto ad altri sistemi di inizializzazione:
- Tutto lo stato viene memorizzato nella RAM, semplificando l'uso in ambienti con partizioni disco in modalità di sola lettura.
- Architettura basata su eventi, che non utilizza il polling.
- Assenza di operazioni di allocazione di memoria durante il funzionamento (tutti i buffer vengono allocati all'avvio).
- Uso limitato dei file descriptor durante il funzionamento.
- Forniamo un file eseguibile autonomo e un'utilità per la gestione del sistema.
- L'assenza di fasi di compilazione della configurazione — il funzionamento del servizio è determinato da script semplici nella directory associata al servizio.
- Presenza di una funzione di riavvio dei servizi dopo un guasto.
- Disponibilità di un meccanismo di logging, che può essere attivato sia di default che selettivamente per singoli servizi.
- Possibilità di costruire una catena di elaborazione del log che coinvolge più servizi.
- Il funzionamento non dipende dalla precisione dell'impostazione degli orologi di sistema.
- Supporto per l'avvio su FreeBSD tramite /etc/ttys.
- Possibilità di assemblaggio sotto forma di un file eseguibile statico in miniatura utilizzando musl libc.
Fonte: opennet.ru
