Opublikowano pierwszy publiczny wydanie projektu Nitro, rozwijającego minimalistyczny system inicjalizacji z funkcjami kontroli przebiegu procesów. Projekt jest prowadzony przez Leah Neukirchen, jedną z osób odpowiedzialnych za pakiety w dystrybucji Void Linux. Kod jest napisany w języku C i rozpowszechniany na licencji 0BSD.
Nitro może działać zarówno jako proces init (pid 1), jak i w postaci nieuprzywilejowanego procesu, który kontroluje nieprzerwane działanie aplikacji w przestrzeni użytkownika i ponownie uruchamia zadania w przypadku awarii. Obsługiwana jest praca w systemach Linux i FreeBSD, a także możliwość zastosowania w środowiskach opartych na standardowej bibliotece C Musl. Wspomniane są obszary zastosowań takie jak systemy wbudowane, obrazy ram-dysków (initramfs), kontenery (Docker/Podman/LXC/Kubernetes), a także stacje robocze i systemy serwerowe. Do zarządzania pracą usług i interakcji z procesem init dostarczany jest narzędzie wiersza poleceń nitroctl.
W Nitro, zamiast złożonych skryptów inicjalizacji, zastosowano model oparty na wyodrębnieniu każdej funkcji do oddzielnego skryptu. Dla każdej usługi w hierarchii /etc/nitro tworzony jest podkatalog, w którym mogą znajdować się następujące skrypty: setup — zawiera polecenia wykonywane przed uruchomieniem usługi; run — definiuje scenariusz uruchamiania usługi; finish — zawiera polecenia wykonywane po zakończeniu usługi. Do organizacji logowania stosowana jest symbolic link o nazwie log, wskazująca na inną usługę, do której będzie kierowane wyjście. Aby wyłączyć autostart usługi, wystarczy utworzyć w jej katalogu plik o nazwie „down”, a aby zignorować usługę należy dodać symbol „@” do nazwy katalogu.
Autor projektu wymienia następujące zalety Nitro w porównaniu do innych systemów inicjalizacji:
- Wszystkie stany są przechowywane w pamięci RAM, co ułatwia pracę w środowiskach z partycjami dyskowymi w trybie tylko do odczytu.
- Architektura oparta na przetwarzaniu zdarzeń, nie używająca mechanizmu polling.
- Brak operacji alokacji pamięci w trakcie działania (wszystkie bufory są alokowane przy uruchomieniu).
- Ograniczone wykorzystanie deskryptorów plików w trakcie działania.
- Dostawany w formie jednego samowystarczalnego pliku wykonywalnego oraz narzędzia do zarządzania systemem.
- Brak etapów kompilacji konfiguracji — działanie usługi określają proste skrypty w katalogu powiązanym z usługą.
- Funkcja ponownego uruchamiania usług po awarii.
- Mechanizm logowania, który może być włączony zarówno domyślnie, jak i wybiórczo dla poszczególnych usług.
- Możliwość budowy łańcucha przetwarzania logów, obejmującego kilka usług.
- Działanie nie zależy od dokładności ustawienia zegarów systemowych.
- Wsparcie dla uruchamiania na FreeBSD przez /etc/ttys.
- Możliwość kompilacji w formie miniaturowego, statycznie skompilowanego pliku wykonywalnego przy użyciu musl libc.
Źródło: opennet.ru
