Может ли процесс init быть сценарием оболочки в Linux?

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

Единственное, чего не хватает - это / init, исполняемый файл в корне initramfs, который выполняется ядром после его загрузки. Поскольку sys-apps / busybox включает в себя полностью функциональную оболочку, это означает, что вы можете написать свой двоичный файл / init в виде простого сценария оболочки (вместо того, чтобы делать его сложным приложением, написанным на ассемблере или 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заменяет весь процесс на месте. Финальный init все еще является первым процессом (pid 1), хотя ему предшествовали те, что были в Initramfs.

Initramfs /init, который является сценарием оболочки Busybox с pid 1, execs для Busybox switch_root(теперь switch_rootэто pid 1); эта программа меняет ваши точки монтирования, поэтому /mnt/rootбудет новой /.

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

Конечно, это можно сделать и с помощью скрипта Python, если вам каким-то образом удалось внедрить Python в свои Initramfs. Хотя если вы все равно не планируете включать busybox, вам придется тщательно реализовать некоторые его функции (например,switch_root , и все остальное, что вы обычно делаете с помощью простой команды).

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

Системный вызов exec ядра Linux изначально недооценивает шебанги

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

• делать и execсистемный вызов
• с исполняемым файлом /bin/sh
• и с аргументом CLI: путь к текущему сценарию

Это то же самое, что происходит при запуске обычного сценария оболочки пользователя с:

./myscript.sh

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

Более подробно на: Почему люди пишут #! / Usr / bin / env pyb shebang в первой строке скрипта Python? | Переполнение стека

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

Вот минимальный работающий пример для тех, кто хочет попробовать это: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/cbea7cc02c868711109ae1a261d01fd0473eea0b#custom-init