Was genau macht init?

System 5 init wird 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 traditionell als auch der beste Ausgangspunkt. Beides ist nicht der Fall.

Tradition ist nicht das, was solche Leute sagen, für den Anfang. System 5 init und System 5 rc Datum bis AT&T UNIX System 5, das fast so weit nach dem ersten UNIX war, wie wir jetzt (sagen wir) nach der ersten Version von Linux-Mandrake sind.

1st Edition UNIX hatte nur init . Es hatte nicht rc . Die Assemblersprache der 1. Ausgabe init (dessen Code von Warren Toomey et al. wiederhergestellt und verfügbar gemacht wurde) hat direkt 12 getty gespawnt und wieder gespawnt Prozesse, hängte 3 festverdrahtete Dateisysteme aus einer eingebauten Tabelle ein und führte direkt ein Programm aus dem Home-Verzeichnis eines Benutzers namens mel aus . Die getty Tabelle war auch direkt im Programmbild.

Es war ein weiteres Jahrzehnt nach UNIX System 5, als das sogenannte "traditionelle" Linux-Init-System auftauchte. 1992 hat Miquel van Smoorenburg einen Linux init (neu) geschrieben +rc , und die zugehörigen Tools, die jetzt als "System 5 init bezeichnet werden ", obwohl es nicht wirklich die Software von UNIX System 5 ist (und nicht nur init ist ).

System 5 init /rc ist nicht der beste Ausgangspunkt, und selbst wenn man Wissen über systemd hinzufügt, deckt das nicht die Hälfte dessen ab, was man wissen muss. Allein in den letzten zwei Jahrzehnten ist viel Arbeit im Bereich des Init-Systemdesigns (für Linux und die BSDs) passiert. Alle möglichen technischen Entscheidungen wurden diskutiert, getroffen, entworfen, implementiert und geübt. Auch die kommerziellen Unices haben viel getan.

Bestehende Systeme zum Studieren und Lernen

Hier ist eine unvollständige Liste einiger der wichtigsten Init-Systeme anders als diese beiden und ein oder zwei ihrer (mehreren) hervorstechenden Punkte:

• Joachim Nilssons finit ging den Weg, eine besser lesbare Konfigurationsdatei zu verwenden.
• Felix von Leitners Minit entschied sich für ein Dateisystem-ist-die-Datenbank-Konfigurationssystem, kleinen Speicherbedarf und Start/Stopp-Abhängigkeiten unter Dingen, die init sind beginnt.
• Gerrit Papes Runit ging für das, was ich zuvor als die nur vier Shell-Skripte spawnen beschrieben habe Ansatz.
• InitNG zielte darauf ab, Abhängigkeiten, benannte Ziele, mehrere Konfigurationsdateien und eine flexiblere Konfigurationssyntax mit einer ganzen Menge mehr Einstellungen für untergeordnete Prozesse zu haben.
• Upstart hat sich für ein komplettes Redesign entschieden und das System nicht als Dienste und gegenseitige Abhängigkeiten modelliert, sondern als Ereignisse und Jobs, die von ihnen ausgelöst werden.
• Das Design von nosh beinhaltet das Verschieben der gesamten Dienstverwaltung (einschließlich sogar der getty Spawning und Zombie-Ernte) in einen separaten Service-Manager, und zwar nur Umgang mit betriebssystemspezifischen "API"-Geräten/Symlinks/Verzeichnissen und Systemereignissen.
• sinit ist eine sehr einfache Initialisierung. Es führt /bin/rc.init aus dessen Aufgabe es ist, Programme zu starten, Dateisysteme zu mounten usw. Dafür können Sie so etwas wie minirc verwenden.

Darüber hinaus gab es vor etwa 10 Jahren eine Diskussion unter Benutzern von Daemontools und anderen über die Verwendung von svscan als Prozess Nr. 1, was zu Projekten wie Paul Jarcs svscan as process 1 study, Gerrit Papes Ideen und Laurent Bercots svscan as process 1 führte.

Das bringt uns zu Prozess Nr. 1 Programmen.

Was Prozess Nr. 1-Programme tun

Vorstellungen darüber, was Prozess Nr. 1 tun soll, sind von Natur aus subjektiv. Ein sinnvolles Ziel Designkriterium ist, was Prozess Nr. 1 mindestens muss tun. Der Kernel stellt mehrere 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 hat getan, dann sind wir nicht auf diesem Minimum und waren es nie wirklich.

Es gibt mehrere Dinge, die verschiedene Betriebssystemkerne und andere Programme von Prozess Nr. 1 verlangen, denen man sich einfach nicht entziehen kann.

Die Leute werden Ihnen sagen, dass fork() Dinge zu speichern und als Elternteil von verwaisten Prozessen zu fungieren, ist die Hauptfunktion von Prozess Nr. 1. Ironischerweise ist dies nicht wahr. Der Umgang mit verwaisten Prozessen ist (mit neueren Linux-Kernels, wie unter https://unix.stackexchange.com/a/177361/5132 erklärt) ein Teil des Systems, den man weitgehend aus Prozess Nr. 1 in andere Prozesse auslagern kann, wie z ein engagierter Service Manager . All dies sind Dienstmanager, die außerhalb von Prozess #1 laufen:

• das IBM AIX srcmstr Programm, dem System Resource Controller
• Gerrit Papes runsvdir von runit
• Daniel J. Bernsteins svscan von daemontools, Adam Sampsons svscan von freedt, Bruce Guenters svscan von daemontools-encore und Laurent Bercots s6-svscan ab s6
• Wayne Marshalls perpd von Täter
• die Service-Management-Einrichtung in Solaris 10
• der service-manager von nosh

Ebenso, wie unter https://superuser.com/a/888936/38062 erklärt, der gesamte /dev/initctl Die Idee muss sich nicht in der Nähe von Prozess Nr. 1 befinden. Ironischerweise ist es das stark zentralisierte systemd, das zeigt, dass es aus Prozess Nr. 1 herausbewegt werden kann.

Umgekehrt die obligatorischen Dinge für init , die die Leute in ihren ausgefallenen Designs normalerweise vergessen, sind Dinge wie der Umgang mit SIGINT , SIGPWR , SIGWINCH , und so weiter, die vom Kernel gesendet werden und die verschiedenen Anforderungen zur Änderung des Systemstatus ausführen, die von Programmen gesendet werden, die "wissen", dass bestimmte Signale an Prozess Nr. 1 bestimmte Dinge bedeuten. (Zum Beispiel:Wie unter https://unix.stackexchange.com/a/196471/5132 erklärt, „wissen“ BSD-Toolsets, dass SIGUSR1 hat eine bestimmte Bedeutung.)

Es gibt auch einmalige Initialisierungs- und Finalisierungsaufgaben, denen man sich nicht entziehen kann oder die sehr darunter leiden, wie 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 init rom 1st Edition UNIX:Man hat eine Liste von Informationen, die fest im Programm verdrahtet sind, und man einfach mount() s alle Einträge in der Liste. Sie finden diesen Mechanismus in so unterschiedlichen Systemen wie BSD (sic!) init , durch die Nosh system-manager , nach systemd.

"das System für eine einfache Shell einrichten"

Wie Sie bemerkt haben, init=/bin/sh erhält keine "API"-Dateisysteme gemountet, stürzt auf unbeholfene Weise ohne Cache-Flush ab, wenn man exit eingibt (https://unix.stackexchange.com/a/195978/5132) und überlässt es im Allgemeinen dem (Super-)Benutzer, die Aktionen manuell auszuführen, die das System minimal nutzbar machen.

Um zu sehen, was man in Prozess-#1-Programmen tatsächlich tun muss, und Sie so auf einen guten Kurs für Ihr erklärtes Designziel zu bringen, ist es am besten, sich die Überschneidungen in der Bedienung von Gerrit Papes Runit Felix von anzusehen Leitners Minit und die system-manager Programm aus dem Nosh-Paket. Die ersten beiden zeigen zwei Versuche, minimalistisch zu sein, aber dennoch mit dem Zeug umzugehen, dem man nicht ausweichen kann.

Letzteres ist nützlich, schlage ich vor, wegen seiner umfangreichen manuellen Eingabe für den system-manager Programm, das genau beschreibt, welche "API"-Dateisysteme gemountet werden, welche Initialisierungsaufgaben ausgeführt werden und welche Signale verarbeitet werden; in einem System, das durch Design hat der Systemmanager nur drei andere Dinge erzeugt (den Dienstmanager, einen begleitenden Logger und das Programm zum Ausführen der Zustandsänderungen) und nur das Unvermeidliche in Prozess #1 erledigt.

System V init unter Debian (es gibt andere Varianten und Variationen) macht Folgendes:

• Beim Betreten eines Runlevels werden Skripte in /etc/rcX.d/S* aufgerufen in alphanumerischer Reihenfolge, wobei X ist der Runlevel. Diese Skripte sollten den Runlevel einrichten. Ein typisches Setup besteht darin, Daemons zu starten und Setup-Aufgaben für diesen Runlevel auszuführen. Dies ist eine einmalige Sache, die beim Betreten des Runlevels gemacht wird.
• In einem Runlevel startet es Daemons, die in /etc/inittab aufgeführt sind als während dieses Runlevels aktiv sein zu müssen. Wenn diese Daemons nicht mehr ausgeführt werden, werden sie neu gestartet. Während Sie jeden Daemon haben können, den Sie von init verwalten lassen möchten , mindestens ein paar getty , damit Sie sich anmelden können. getty beendet, sobald eine Anmeldung abgeschlossen ist, dann init startet es neu und liefert eine neue Anmeldeaufforderung.
  
  • Wenn der Daemon zu oft in zu kurzer Zeit neu gestartet wird, hört er für eine Weile auf, ihn neu zu starten.
  • Nur weil etwas von den Kickoff-Skripten beim Betreten des Runlevels gestartet wurde, macht es nicht init automatisch versuchen, es am Laufen zu halten. Das müssen Sie separat im /etc/inittab angeben .
• Beim Verlassen eines Runlevels werden Skripte in /etc/rcX.d/K* aufgerufen in alphanumerischer Reihenfolge, wobei X ist der Runlevel. Eine Möglichkeit, das Herunterfahren oder Neustarten zu implementieren, besteht darin, einen Runlevel für diese Ereignisse zu definieren und die letzte ausgeführte Aufgabe zum halt zu machen oder reboot Befehl.
• Es ruft ausführbare Dateien als Reaktion auf bestimmte Ereignisse auf, wie z. B. Einschaltereignisse oder Strg-Alt-Entf.
• Es lauscht auf einem Socket, wenn es bestimmte Nachrichten erhält, ändert es den Runlevel.

Sie können also init verwenden als rudimentärer Servicemanager, wenn Sie wollen, aber seine Hauptaufgabe ist heutzutage, getty zu behalten ist verfügbar, damit sich ein Benutzer anmelden und Runlevel-Übergänge starten kann.

Ich habe mich nur gefragt, welche Aufgaben Init übernimmt, um das System für eine einfache Shell einzurichten?

Irgendwas du willst. Unter Debian in jedem /etc/rcX.d Verzeichnis ist ein symbolischer Link zu einem Skript in /etc/init.d und Sie können diese Skripte vollständig anpassen oder entfernen. Die Reihenfolge wird festgelegt, indem jedem Skript ein 00 vorangestellt wird , 01 usw.

Sie können auch einen -b angeben Option zu init (d. h. über die Kernel-Befehlszeile), wenn Sie nur init möchten eine Muschel zu spawnen. Wenn Sie die Shell verlassen, init stirbt und wenn init stirbt, gerät der Kernel in Panik.

Das absolute Minimum, das init tun muss, ist, mindestens ein anderes Programm auszuführen und niemals zu beenden. Wenn init beendet wird, stürzt das System ab. Ich nehme an, dass nicht einmal das Ausführen des einen anderen Programms unbedingt erforderlich ist, aber wenn Sie das nicht tun, müsste init dafür verantwortlich sein, alles zu tun, was das System tun soll, oder es wäre nicht sehr nützlich.