Le système 5 initne vous racontera qu'une petite partie de l'histoire.
Il y a une sorte de myopie qui affecte le monde Linux. Les gens pensent qu’ils utilisent un élément appelé «Système 5 init», c’est à la fois ce qui est traditionnel et le meilleur endroit pour commencer. Ce n'est en fait pas le cas.
La tradition n'est en fait pas ce que de telles personnes disent, pour commencer. System 5 initet System 5 rcremontent à AT & T UNIX System 5, qui était presque aussi loin après le premier UNIX que nous le sommes maintenant (par exemple) après la première version de Linux-Mandrake.
1ère édition sous UNIX seulement init. Il n'a pas eu rc. Le langage assembleur de la 1re édition init( dont le code a été restauré et mis à disposition par Warren Toomey et autres ) a directement engendré et réapparu 12 gettyprocessus, monté 3 systèmes de fichiers câblés à partir d'une table intégrée et exécuté directement un programme à partir du répertoire de base d'un utilisateur nommé mel. La gettytable était aussi directement dans l'image du programme.
Dix ans après UNIX System 5, le soi-disant système d'initiation Linux "traditionnel" est apparu. En 1992, Miquel van Smoorenburg (re-) a écrit un Linux init+ rcet ses outils associés, que les gens appellent maintenant "Système 5 init", même s’il ne s’agit pas du logiciel UNIX Système 5 (et init).
System 5 init/ rcn'est pas le meilleur endroit pour commencer, et même si on ajoute une connaissance de systemd qui ne couvre pas la moitié de ce qu'il y a à savoir. Beaucoup de travail dans le domaine de la conception de systèmes init (pour Linux et les BSD) a eu lieu au cours des deux dernières décennies seulement. Toutes sortes de décisions d'ingénierie ont été discutées, prises, conçues, mises en œuvre et mises en pratique. Les Unices commerciaux ont également fait beaucoup.
Systèmes existants pour étudier et apprendre de
Voici une liste incomplète de quelques-uns des principaux systèmes d’initialisation autres que ceux-là, et un ou deux de leurs (plusieurs) points saillants:
- Joachim Nilsson a fini par utiliser un fichier de configuration plus lisible par l'homme.
- Le service de Felix von Leitner a opté pour un système de configuration système de fichiers, tel que la base de données, de petites empreintes de mémoire et des dépendances de démarrage / arrêt
init.
- La campagne de Gerrit Pape a opté pour ce que j'ai décrit précédemment comme l' approche des quatre scripts shell .
- InitNG visait à avoir des dépendances, des cibles nommées, plusieurs fichiers de configuration et une syntaxe de configuration plus flexible avec un chargement complet de paramètres pour les processus enfants.
- Upstart a entrepris une refonte complète en modélisant le système non pas comme des services et des interdépendances, mais comme des événements et des tâches déclenchées par ceux-ci.
- La conception de Nosh comprend pousser toute la gestion des services (y compris celles même le
gettyfrai et zombie récolte) dans un gestionnaire de service distinct et simplement la manipulation du système d' exploitation spécifique « API » périphériques / symlinks / répertoires et les événements du système.
- Sinit est un init très simple. Il exécute
/bin/rc.initle travail pour lancer les programmes, monter le système de fichiers, etc. Pour cela, vous pouvez utiliser quelque chose comme minirc .
En outre, il y a environ 10 ans, les utilisateurs de daemontools et d’autres utilisateurs ont discuté de l’utilisation du svscanprocessus n ° 1, qui a donné lieu à des projets tels que svscan de Paul Jarc en tant que processus 1 , idées de Gerrit Pape et le processus de Laurent Bercot en tant que processus 1 .
Ce qui nous amène à ce que font les processus n ° 1.
Quel processus font les programmes # 1
Les notions de ce que le processus n ° 1 est "supposé" faire sont subjectives par leur nature. Un critère de conception objectif significatif est ce que le processus n ° 1 doit au moins faire. Le noyau lui impose plusieurs exigences. Et il doit toujours faire certaines choses spécifiques au système d'exploitation. En ce qui concerne ce processus # 1 a toujours fait, nous ne sommes pas à ce minimum et ne jamais avoir vraiment été.
Il existe plusieurs choses que divers noyaux de systèmes d'exploitation et autres programmes exigent du processus n ° 1 et auxquelles on ne peut tout simplement pas échapper.
Les gens vous diront que fork()manipuler les choses et agir en tant que parent de processus orphelins est la fonction première du processus n ° 1. Ironiquement, c'est faux. Le traitement des processus orphelins est (avec les noyaux Linux récents, comme expliqué à l’ adresse https://unix.stackexchange.com/a/177361/5132 ) un élément du système que l’on peut largement intégrer au processus n ° 1 dans d’autres processus, tels que un responsable de service dédié . Ce sont tous des gestionnaires de services, qui exécutent le processus n ° 1:
De même, comme expliqué à l' adresse https://superuser.com/a/888936/38062 , il /dev/initctln'est pas nécessaire que l'idée soit proche du processus n ° 1. Ironiquement, c’est le système hautement centralisé qui démontre qu’il peut être sorti du processus n ° 1.
A l' inverse, les choses obligatoires pour initque les gens oublient souvent dans leurs hors-la-haut de la tête conceptions, des choses telles que la manipulation SIGINT, SIGPWR, SIGWINCHet ainsi de suite envoyé par le noyau et l' adoption de diverses demandes de changement d'état du système envoyé des programmes qui "savent" que certains signaux à traiter # 1 signifient certaines choses. (Par exemple: comme expliqué à l' adresse https://unix.stackexchange.com/a/196471/5132 , les jeux d'outils BSD "savent" SIGUSR1avec une signification spécifique.)
Il existe également des tâches uniques d'initialisation et de finalisation auxquelles on ne peut pas échapper ou qui vont beaucoup souffrir, telles que le montage de systèmes de fichiers "API" ou le vidage du cache du système de fichiers.
Les principes de base de la gestion des systèmes de fichiers "API" diffèrent peu du fonctionnement de la init1ère édition UNIX: l’une a une liste d’informations intégrées dans le programme, et une autre simplement mount()toutes les entrées de la liste. Vous trouverez ce mécanisme dans des systèmes aussi divers que BSD (sic!) init, En passant par nosd system-manager, à systemd.
"configurer le système pour un simple shell"
Comme vous l'avez constaté, les init=/bin/shsystèmes de fichiers "API" ne sont pas montés, se bloque de façon disproportionnée sans mémoire cache quand on tape exit( https://unix.stackexchange.com/a/195978/5132 ), et le laisse généralement au (super) utilisateur de faire manuellement les actions qui rendent le système utilisable de manière minimale.
Pour voir ce que l'on n'a pas d'autre choix que de faire dans le processus n ° 1, et ainsi vous mettre sur la bonne voie pour votre objectif de conception déclaré, votre meilleure option est d'examiner les chevauchements dans le fonctionnement du runit de Gerrit Pape, Felix von. Leitner's minit et le system-managerprogramme du paquet nosh. Les deux premiers montrent deux tentatives d’être minimaliste, tout en conservant ce qu’il est impossible d’éviter.
Ce dernier est utile, je le suggère, pour son entrée manuelle complète pour le system-managerprogramme, qui détaille exactement quels systèmes de fichiers "API" sont montés, quelles tâches d’initialisation sont exécutées et quels signaux sont gérés; dans un système qui, de par sa conception, le gestionnaire de système génère simplement trois autres choses (le gestionnaire de services, un enregistreur associé et le programme permettant d'exécuter les modifications d'état) et effectue uniquement l'inévitable processus n ° 1.