Чи може процес init бути скриптом оболонки в Linux?

Я переглядав підручник із налаштування користувальницьких initramfs, де зазначено:

Єдине, чого не вистачає, це / init, виконуваний файл у корені initramfs, який виконується ядром після його завантаження. Оскільки sys-apps / busybox включає повністю функціональну оболонку, це означає, що ви можете написати / init бінарний файл як простий скрипт оболонки (замість того, щоб зробити це складним додатком, написаним в Assembler або C, який потрібно компілювати).

і наводить приклад init як сценарію оболонки, який починається з #!/bin/busybox sh

Поки що у мене було враження, що init - це основний процес, який запускається, і що всі інші процеси в просторі користувачів - врешті-решт діти init. Однак у наведеному прикладі перший процес є насправді, bin/busybox/ shз якого пізніше породжується init.

Це правильна інтерпертація? Якби у мене, наприклад, був доступний перекладач у той момент, я міг би написати init як сценарій Python тощо?

init не "породжений" (як дочірній процес), а скоріше execтак:

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

execзамінює весь процес на місці. Заключний ініт все ще є першим процесом (pid 1), навіть незважаючи на те, що йому передували ті, які були в Initramfs.

Initramfs /init, що являє собою скрипт оболонки Busybox з pid 1, execs до Busybox switch_root(так це зараз switch_rootpid 1); ця програма змінює ваші точки монтажу, тому /mnt/rootбуде новою /.

switch_rootпотім знову від execs до /sbin/initвашої реальної кореневої файлової системи; тим самим це робить вашу справжню систему init першим процесом з підпискою 1, який, в свою чергу, може породити будь-яку кількість дочірніх процесів.

Звичайно, це було б так само добре, як і з сценарієм Python, якщо вам якимось чином вдалося вписати Python у свій Initramfs. Хоча якщо ви все одно не плануєте включати зайнятий ящик, вам доведеться кропітко повторно реалізувати частину його функціональності (наприклад switch_root, і все інше, що ви зазвичай робите за допомогою простої команди).

Однак це не працює на ядрах, які не дозволяють бінарних файлів скриптів ( CONFIG_BINFMT_SCRIPT=y), точніше, у такому випадку вам доведеться запустити інтерпретатор безпосередньо та змусити його якось завантажувати ваш сценарій.

Система exec виклику ядра Linux спочатку розуміє shebangs

Коли виконаний файл починається з магічних байтів #!, вони кажуть ядро ​​використовувати #!/bin/shяк:

• робити і execсистемний виклик
• з виконуваним файлом /bin/sh
• та з аргументом CLI: шлях до поточного сценарію

Це саме те, що відбувається, коли ви запускаєте звичайний сценарій оболонки користувача з:

./myscript.sh

Якби файл почався .ELFзамість магічних байтів #!, ядро ​​вибрало б завантажувач ELF замість того, щоб запустити його.

Детальніше на сторінці: Чому люди записують #! / Usr / bin / env python shebang в перший рядок сценарію Python? | Переповнення стеку

Коли ви це пам’ятаєте, стає легко визнати, /initщо ядро ​​може виконати, включаючи скрипт оболонки, а також, чому /bin/sh, в цьому випадку стане першим виконуваним файлом.

Ось мінімальний приклад для тих, хто хоче спробувати його: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/cbea7cc02c868711109ae1a261d01fd0473eea0b#custom-init