Czy proces init może być skryptem powłoki w systemie Linux?

Przechodziłem samouczek na temat konfigurowania niestandardowego initramfs, w którym napisano:

Jedyne czego brakuje to / init, plik wykonywalny w katalogu głównym initramfs, który jest wykonywany przez jądro po załadowaniu. Ponieważ sys-apps / busybox zawiera w pełni funkcjonalną powłokę, oznacza to, że możesz napisać swój plik binarny / init jako prosty skrypt powłoki (zamiast robić z niego skomplikowaną aplikację napisaną w Asemblerze lub C, którą musisz skompilować).

i podaje przykład init jako skrypt powłoki, który zaczyna się od #!/bin/busybox sh

Do tej pory miałem wrażenie, że init jest głównym procesem, który jest uruchamiany i że wszystkie inne procesy przestrzeni użytkownika są ostatecznie potomkami init. Jednak w podanym przykładzie tak naprawdę pierwszy proces jest bin/busybox/ shinicjowany.

Czy to poprawna interpretacja? Gdybym na przykład miał w tym momencie dostępnego interpretera, mógłbym napisać init jako skrypt Pythona itp.?

init nie jest „spawnowany” (jako proces potomny), ale raczej exectak:

# Boot the real thing.
exec switch_root /mnt/root /sbin/init

execzastępuje cały proces na miejscu. Ostateczna inicjacja jest nadal pierwszym procesem (pid 1), mimo że była poprzedzona tymi w Initramfs.

Initramfs /init, który jest skryptem powłoki Busybox z pid 1, execs do Busybox switch_root(teraz switch_rootjest to pid 1); ten program zmienia punkty montowania, więc /mnt/rootbędzie nowy /.

switch_rootnastępnie ponownie execs do /sbin/inittwojego prawdziwego głównego systemu plików; w ten sposób twój prawdziwy system inicjujący jest pierwszym procesem z pid 1, który z kolei może spawnować dowolną liczbę procesów potomnych.

Z pewnością można to równie dobrze zrobić za pomocą skryptu Python, jeśli w jakiś sposób udało się upiec Pythona w Initramfs. Chociaż jeśli i tak nie planujesz dołączać do busyboksa, musiałbyś z należytą starannością zaimplementować niektóre jego funkcje (takie jak switch_rootwszystko inne, co zwykle robisz za pomocą prostego polecenia).

Jednak nie działa na jądrach, które nie zezwalają na pliki binarne skryptów ( CONFIG_BINFMT_SCRIPT=y), a raczej w takim przypadku będziesz musiał uruchomić interpreter bezpośrednio i zmusić go do załadowania skryptu.

Wywołanie systemowe jądra Linuksa natywnie nie docenia shebangów

Kiedy wykonywany plik zaczyna się od bajtów magicznych #!, informuje jądro, aby używało go #!/bin/shjako:

• do i execwywołanie systemowe
• z plikiem wykonywalnym /bin/sh
• oraz z argumentem CLI: ścieżka do bieżącego skryptu

Dokładnie tak samo dzieje się po uruchomieniu zwykłego skryptu powłoki użytkownika z:

./myscript.sh

Gdyby plik zaczął się od bajtów magicznych .ELFzamiast #!, jądro wybrałoby moduł ładujący ELF, aby go uruchomić.

Więcej informacji: Dlaczego ludzie piszą #! / Usr / bin / env shebang python w pierwszym wierszu skryptu Python? | Przepełnienie stosu

Kiedy to sobie przypomnisz, łatwo będzie zaakceptować, że /initmoże to być wszystko co jądro może wykonać, w tym skrypt powłoki, a także dlaczego /bin/shbędzie to pierwszy plik wykonywalny w tym przypadku.

Oto minimalny uruchamialny przykład dla tych, którzy chcą go wypróbować: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/cbea7cc02c868711109ae1a261d01fd0473eea0b#custom-init