System 5 initwird Ihnen nur einen kleinen Teil der Geschichte erzählen.
Es gibt eine Art Kurzsichtigkeit, die die Linux-Welt betrifft. Die Leute denken, dass sie ein Ding namens "System 5 init" verwenden, und das ist sowohl das, was traditionell ist, als auch der beste Ausgangspunkt. Weder ist in der Tat der Fall.
Tradition ist eigentlich nicht das, was solche Leute sagen. System 5 initund System 5 rcdatieren auf AT & T UNIX System 5, das fast so weit nach dem ersten UNIX war, wie wir es jetzt (etwa) nach der ersten Version von Linux-Mandrake sind.
Erstausgabe hatte nur UNIX init. Es hatte nicht rc. Die erste Ausgabe der Assemblersprache init( Code derer wurde restauriert und zur Verfügung gestellt von Warren Toomey et al. ) Direkt hervorgebracht und respawned 12 gettyProzesse, 3 montiert fest verdrahtet Dateisysteme von einem eingebauten Tisch und lief ein Programm direkt aus dem Home - Verzeichnis einer benutzername mel. Die gettyTabelle befand sich auch direkt im Programmabbild.
Es war ein weiteres Jahrzehnt nach UNIX System 5, als das sogenannte "traditionelle" Linux-Init-System auf den Markt kam. 1992 schrieb Miquel van Smoorenburg ein Linux init+ rcund die dazugehörigen Tools (neu), die heute als "System 5 init" bezeichnet werden, obwohl es sich eigentlich nicht um die Software von UNIX System 5 handelt (und das nicht nur) init).
System 5 init/ rcist nicht der beste Ausgangspunkt, und selbst wenn man Kenntnisse über systemd hinzufügt, die nicht die Hälfte des Wissens abdecken. Auf dem Gebiet des Init-Systemdesigns (für Linux und die BSDs) wurde allein in den letzten zwei Jahrzehnten viel Arbeit geleistet. Alle möglichen technischen Entscheidungen wurden diskutiert, getroffen, entworfen, implementiert und umgesetzt. Auch die Commercial Unices haben viel getan.
Bestehende Systeme zum Lernen und Lernen
Hier ist eine unvollständige Liste einiger der wichtigsten Init-Systeme außer diesen beiden und einem oder zwei ihrer (mehreren) hervorstechenden Punkte:
- Joachim Nilsson finit ging die Route der eine für Menschen lesbare Konfigurationsdatei.
- Felix von Leitners Ziel war ein Dateisystem-ist-die-Datenbank-Konfigurationssystem, ein kleiner Speicherbedarf und Start / Stopp-Abhängigkeiten, unter anderem, wenn es
initlosgeht.
- Gerrit Papes Runit ging auf das über, was ich zuvor als den Ansatz mit nur vier Spawn-Shellskripten beschrieben habe .
- InitNG zielte darauf ab, Abhängigkeiten, benannte Ziele, mehrere Konfigurationsdateien und eine flexiblere Konfigurationssyntax mit einer ganzen Reihe von Einstellungen für untergeordnete Prozesse zu haben.
- upstart entschied sich für eine komplette Neugestaltung und modellierte das System nicht als Dienste und Abhängigkeiten, sondern als von ihnen ausgelöste Ereignisse und Jobs.
- Das Design von nosh beinhaltet, dass das gesamte Service-Management (einschließlich des Laichens und Erntens von
gettyZombies) in einen separaten Service-Manager verlagert wird und nur betriebssystemspezifische "API" -Geräte / Symlinks / Verzeichnisse und Systemereignisse verarbeitet werden.
- sinit ist eine sehr einfache Init. Es führt aus,
/bin/rc.initwessen Aufgabe es ist, Programme zu starten, das Dateisystem zu mounten usw. Hierfür können Sie so etwas wie minirc verwenden .
Darüber hinaus gab es vor ungefähr 10 Jahren eine Diskussion unter Daemontools-Anwendern und anderen über die Verwendung svscanals Prozess 1, die zu Projekten wie Paul Jarcs Svscan als Prozess 1-Studie , Gerrit Papes Ideen und Laurent Bercots Svscan als Prozess 1 führte .
Das bringt uns zu dem, was die Programme von Prozess 1 leisten.
Welchen Prozess # 1 Programme tun
Vorstellungen davon, was der Prozess Nr. 1 "tun soll", sind ihrer Natur nach subjektiv. Ein aussagekräftiges objektives Entwurfskriterium ist das, was Prozess 1 mindestens leisten muss . Der Kernel stellt verschiedene Anforderungen an ihn. Und es gibt immer einige betriebssystemspezifische Dinge verschiedener Art, die es zu tun hat. Wenn es darum geht, was Prozess Nr. 1 traditionell getan hat, dann sind wir nicht bei diesem Minimum und haben es nie wirklich getan.
Es gibt einige Dinge, die verschiedene Betriebssystemkerne und andere Programme von Prozess 1 verlangen, denen man sich einfach nicht entziehen kann.
Die Leute werden Ihnen sagen, dass fork()die Hauptfunktion von Prozess 1 darin besteht , Dinge zu erledigen und als Eltern verwaister Prozesse zu agieren. Ironischerweise ist das nicht wahr. Der Umgang mit verwaisten Prozessen ist (bei neueren Linux-Kerneln, wie unter https://unix.stackexchange.com/a/177361/5132 erläutert ) ein Teil des Systems, den man in anderen Prozessen, wie z ein engagierter Service-Manager . All dies sind Service-Manager, die nicht mit Prozess 1 konfrontiert sind:
- das IBM AIX-
srcmstrProgramm, der System Resource Controller
- Gerrit Pape ist
runsvdirvon runit
- Daniel J. Bernstein
svscanvon daemontools, Adam Sampson svscanvon freedt , Bruce Guenter svscanvon daemontools-encore und Laurent Bercot s6-svscanvon s6
- Wayne Marshall ist
perpdvon perp
- die Service Management Facility in Solaris 10
- das
service-managervon nosh
Ebenso muss, wie unter https://superuser.com/a/888936/38062 erläutert , die gesamte /dev/initctlIdee nicht in der Nähe von Prozess 1 liegen. Ironischerweise ist es das stark zentralisierte System, das zeigt, dass es aus Prozess 1 herausbewegt werden kann.
Umgekehrt ist für die obligatorischen Dinge init, in der Regel , dass die Menschen in ihrem off-the-top-of-the-Kopf - Design vergessen, sind Dinge wie Handhabung SIGINT, SIGPWR, SIGWINCHund so weiter aus dem Kernel gesendet und die verschiedenen Systemstatusänderungsanforderungen erlassen gesendet von Programmen, die "wissen", dass bestimmte Signale, um # 1 zu verarbeiten, bestimmte Dinge bedeuten. (Zum Beispiel: Wie unter https://unix.stackexchange.com/a/196471/5132 erläutert , "wissen" BSD-Toolsets, dass SIGUSR1sie eine bestimmte Bedeutung haben.)
Es gibt auch einmalige Initialisierungs- und Finalisierungsaufgaben, denen man sich nicht entziehen kann oder die sehr unter Umständen nicht ausgeführt werden, z. B. das Mounten von "API" -Dateisystemen oder das Leeren des Dateisystem-Cache.
Die Grundlagen des Umgangs mit "API" -Dateisystemen unterscheiden sich kaum von der Funktionsweise von initUnix der ersten Edition: Man hat eine Liste mit Informationen, die fest im Programm verankert sind, und man hat einfach mount()alle Einträge in der Liste. Sie werden diesen Mechanismus in Systemen finden, die so unterschiedlich sind wie BSD (sic!) init, Von nosh system-managerbis systemd.
"Richten Sie das System für eine einfache Shell ein"
Wie Sie bereits bemerkt haben, werden init=/bin/sh"API" -Dateisysteme nicht gemountet, stürzen in ungünstiger Weise ohne Cache-Flush ab, wenn ein Typ exit( https://unix.stackexchange.com/a/195978/5132 ) eingibt , und lassen es im Allgemeinen an den (Super-) Benutzer, die Aktionen, die das System minimal nutzbar machen, manuell durchzuführen.
Um zu sehen, was man eigentlich keine andere Wahl hat, als in den Programmen Nr. 1 zu arbeiten, und Sie so auf einen guten Kurs für Ihr erklärtes Designziel zu bringen, ist es Ihre beste Option, die Überschneidungen in der Funktionsweise von Gerrit Papes runit, Felix von, zu untersuchen Leitners Minit und das system-managerProgramm aus dem Nosh-Paket. Die beiden ersteren zeigen zwei Versuche, minimalistisch zu sein und dennoch mit den Dingen umzugehen, die man nicht vermeiden kann.
Letzteres ist nützlich, ich schlage vor, für seine umfangreiche manuelle Eingabe für das system-managerProgramm, die genau angibt, welche "API" -Dateisysteme eingehängt sind, welche Initialisierungsaufgaben ausgeführt werden und welche Signale behandelt werden; in einem System , das durch Design der Systemmanager nur laichen drei andere Dinge (die Service - Manager, ein Begleitlogger und das Programm ausführen , um die Zustandsänderungen) und nur tun , um die unvermeidlich in Prozess # 1 hat.