Was wäre, wenn der Bootvorgang folgendermaßen aussehen würde:
Übergeben Sie INIT=/bin/sh(or /bin/bash)den Parameter über die GRUB-Befehlszeile oder auf ähnliche Weise an den Kernel und booten Sie dann.
Sobald die Shell geladen ist, beenden Sie sie sofort. Anschließend reagiert der Computer nicht mehr auf gedrückte Tasten.
Ich bin sehr neugierig auf dieSTATUSdes Systems in diesem Moment. Wie ich erfahren habe, initist dies der erste Prozess, der ausgeführt wird, sobald der Kernel geladen ist und alle anderen Prozesse von ihm ausgeführt werden . Wenn es wie oben beschrieben ausgeführt wird, anstatt mit dem normalen Startvorgang, forkscheint das System keine Prozesse mehr zu haben und nichts zu tun./bin/shinit
Ist es im Leerlauf wie Laufen
while (1) {
sleep(1);
}
oder was sonst?
Vielen Dank an Sie alle für Ihre Ratschläge.Vielleicht sind weitere Informationen hilfreich,was ich früher für unnötig hielt.
Ich habe kürzlich an einem CentOS 7.2-Server gearbeitet, und eine XFS-Festplattenpartition ist nicht normal, was beim Systemstart unendlich viel Zeit kostete, sie zu überprüfen und wiederherzustellen. Ich wollte die /etc/fstabautomatische Einbindung dieser Partition durch Bearbeiten deaktivieren. Da der normale Startvorgang hängen blieb, ließ ich init=/bin/bashdas System in Bash booten. Nach dem Bearbeiten fstabführte ich die Shell exitunachtsam aus.dann keine Reaktion auf dem Bildschirm auf irgendeine Taste gedrückt, einschließlich Ctrl-Alt-Del, und keine Informationen ausgelöst Kernel Panic(Ich konnte nicht sagen, ob die CPU hart arbeitete, weil es in dem Raum sehr laut war). Ich betrachtete es als Leerlauf, als ob es einfach nichts zu tun gäbe. Dieses Phänomen ließ mich über die Frage nachdenken, die ich am Anfang aufgeschrieben hatte.
Und ich habe heute Abend einige Tests auf meinem eigenen Notebook mit Debian 8 durchgeführt.Kernpanik offensichtlich.
Antwort1
Ich bin überrascht. Ich hatte verstanden, dass das Beenden von PID 1verursacht eine Kernel-Panik. Ich kann Ihnen sagen, was in diesem Fall passiert ist.
Das Panikverhalten ist konfigurierbar. Mit den Standardeinstellungen erreichen Sie eineSchleifedas sieht genauso aus, wie du sagst.
Die verwendete Verzögerungsfunktion istdokumentiertals "Busy-Wait". Es istnichtEs wird erwartet, dass die CPU in den stromsparenden Ruhezustand wechselt, der bei normalem Leerlauf des Betriebssystems verwendet wird.
Wenn Sie sich den Backtrace ansehen, der von der Panik ausgegeben wird, sehen Sie, dass das alles innerhalb von passiert sys_exit(). Ich denke, technisch gesehen wird PID 1 nicht zerstört, es kehrt nur nie von diesem Systemaufruf zurück. Alle anderen CPUs werden zuerst gestoppt.
(Es gibt etwas, das heißt"Leerlauf-Thread booten". Ich sehe es nicht in diesen Prozess involviert. Soweit ich weiß, kann man diesen Thread nie sehen. Und wenn man ihn als Leerlauf-Thread verstehen wollte, müsste man auch fragen, was den Leerlauf-Thread für die anderen CPUs bereitstellt, sobald sie online gebracht werden).
Antwort2
Es stimmt nicht, dass das System nichts zu tun hat, wenn kein Prozess auf Benutzerebene läuft. Das System hat eine Reihe vonKernel-Threads, die der Kernel selbst gestartet hat. Sie schlafen meistens, werden aber regelmäßig geweckt, um ihre Aufgabe zu erledigen. Kernel-Threads führen nur Code im Kernel-Bereich aus, d. h. sie haben keine Speicherzuordnungen auf Benutzerebene. Sie sind separate Prozesse, da sie unabhängig geplant werden und eindeutige Prozess-IDs haben.
Wenn Sie ausführen ps aux, können Sie die Kernel-Threads an den eckigen Klammern erkennen, die die Thread-Namen umgeben.
Antwort3
Auf dem System läuft kein Prozess. Es gibt also keine Busy-Loop wie von Ihnen beschrieben (die 100 % CPU-Auslastung hätte). Interrupts könnten zwar immer noch vom Kernel verarbeitet werden, aber es gibt keinen Prozess. Die CPU wäre im Leerlauf.
Die Details finden Sie hier imQuelle von kernel_init(), das Programm wird ähnlich wie ausgeführt execve(). Das bedeutet auch, dass die Ausführung nicht zurückkehrt (siehe execve(3p)).