Le processus init peut-il être un script shell sous Linux?

Je suivais un tutoriel sur la configuration d'un initramfs personnalisé où il est indiqué:

La seule chose qui manque est / init, l'exécutable à la racine des initramfs qui est exécuté par le noyau une fois qu'il est chargé. Parce que sys-apps / busybox inclut un shell entièrement fonctionnel, cela signifie que vous pouvez écrire votre binaire / init comme un script shell simple (au lieu d'en faire une application compliquée écrite en Assembleur ou en C que vous devez compiler).

et donne un exemple d'init comme script shell qui commence par #!/bin/busybox sh

Jusqu'à présent, j'avais l'impression que init est le processus principal qui est lancé et que tous les autres processus de l'espace utilisateur sont finalement des enfants d'init. Cependant, dans l'exemple donné, le premier processus est en fait à bin/busybox/ shpartir duquel init est généré plus tard.

Est-ce une interpertation correcte? Si je disposais, par exemple, d'un interprète disponible à ce stade, je pourrais écrire init en tant que script Python, etc.?

init n'est pas "généré" (comme un processus enfant), mais plutôt execcomme ceci:

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

execremplace l'ensemble du processus en place. L'init final est toujours le premier processus (pid 1), même s'il a été précédé de ceux des Initramfs.

Initramfs /init, qui est un script shell Busybox avec pid 1, execs vers Busybox switch_root(alors maintenant switch_rootc'est pid 1); ce programme modifie vos points de montage /mnt/rootsera donc le nouveau /.

switch_rootpuis à nouveau execsur /sbin/initvotre véritable système de fichiers racine; ainsi, il fait de votre véritable système d'initialisation le premier processus avec pid 1, qui à son tour peut engendrer un nombre illimité de processus enfants.

Certes, cela pourrait tout aussi bien être fait avec un script Python, si vous avez réussi à intégrer Python dans vos Initramfs. Bien que si vous ne prévoyez pas d'inclure busybox de toute façon, vous devrez réimplémenter soigneusement certaines de ses fonctionnalités (comme switch_root, et tout ce que vous feriez habituellement avec une simple commande).

Cependant, cela ne fonctionne pas sur les noyaux qui n'autorisent pas les binaires de script ( CONFIG_BINFMT_SCRIPT=y), ou plutôt dans un tel cas, vous devrez démarrer l'interpréteur directement et lui faire charger votre script d'une manière ou d'une autre.

L'appel système du noyau Linux comprend nativement les shebangs

Lorsque le fichier exécuté commence par les octets magiques #!, ils indiquent au noyau d'utiliser #!/bin/shcomme:

• faire et execappel système
• avec exécutable /bin/sh
• et avec l'argument CLI: chemin d'accès au script actuel

C'est exactement la même chose qui se produit lorsque vous exécutez un script shell utilisateur normal avec:

./myscript.sh

Si le fichier avait commencé avec les octets magiques .ELFau lieu de #!, le noyau choisirait le chargeur ELF à la place pour l'exécuter.

Plus de détails sur: Pourquoi les gens écrivent le shebang python #! / Usr / bin / env sur la première ligne d'un script Python? | Débordement de pile

Une fois que vous avez cela à l'esprit, il devient facile d'accepter que cela /initpuisse être tout ce que le noyau peut exécuter, y compris un script shell, et aussi pourquoi ce /bin/shsera le premier exécutable dans ce cas.

Voici un exemple exécutable minimal pour ceux qui veulent l'essayer: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/cbea7cc02c868711109ae1a261d01fd0473eea0b#custom-init