init

Pierwszy proces uruchamiany przez jądro w przestrzeni użytkownika (PID 1), przodek wszystkich pozostałych procesów. We współczesnych systemach jego rolę pełni zwykle systemd.

init to pierwszy proces, który jądro Linuksa uruchamia w przestrzeni użytkownika zaraz po starcie systemu. Dostaje PID 1 i jest przodkiem wszystkich pozostałych procesów — każdy program, który odpalasz, pochodzi w prostej linii właśnie od niego. Jądro startuje, montuje system plików, a potem oddaje stery jednemu procesowi i mówi: „dalej radź sobie sam”. Tym procesem jest init.

Do czego to służy

init ma dwa główne zadania. Po pierwsze, doprowadza system do stanu używalności: uruchamia usługi (sieć, logowanie, demony), montuje dyski, ustawia środowisko. Po drugie, pełni rolę opiekuna sierot — gdy jakiś proces-rodzic umrze przed swoim dzieckiem, osierocone dziecko jest „adoptowane” przez PID 1. To init odbiera ich kod wyjścia (tzw. reaping), dzięki czemu nie zostają zombie blokujące tablicę procesów.

Kluczowa konsekwencja: jeśli PID 1 padnie, jądro wpada w panikę (kernel panic) i system się zatrzymuje. Dlatego ten proces musi być wyjątkowo stabilny.

W praktyce

Na większości współczesnych dystrybucji (Ubuntu, Debian, Fedora, Arch) rolę init przejął systemd. Zarządzasz nim przez systemctl, na przykład:

  • systemctl status nginx — sprawdza, czy usługa działa,
  • systemctl restart sshd — restartuje demona,
  • journalctl -u docker — pokazuje logi konkretnej usługi.

Chcesz zobaczyć, kto faktycznie siedzi na PID 1? Wpisz ps -p 1 -o comm=. Na systemd dostaniesz systemd, na starszym systemie albo w minimalnym kontenerze możesz zobaczyć init, bash czy sh.

Częste mity i pułapki

„init to zawsze systemd” — nie. To tylko najpopularniejszy dziś wybór. Żyją i mają się dobrze alternatywy: SysVinit (klasyczne skrypty w /etc/init.d), OpenRC (Gentoo, Alpine) czy runit. Upstart z kolei to już historia.

Druga pułapka dotyczy kontenerów. W Dockerze proces, który podasz jako CMD, dostaje PID 1 — ale zwykła aplikacja nie umie reapować sierot ani poprawnie obsłużyć sygnałów (SIGTERM). Stąd zombie i kontenery, które nie chcą się ładnie zatrzymać. Lekarstwem jest mały init, np. flaga docker run --init (uruchamia tini) albo dumb-init.

Pojęcia powiązane: PID, proces zombie, systemd, demon (daemon), runlevel/target, fork i exec, sygnały (SIGTERM, SIGKILL), kernel panic.