Unter UNIX dachte ich, wenn ein übergeordneter Prozess verschwindet, dass alle untergeordneten Prozesse init als übergeordneten zurücksetzen. Ist das nicht immer richtig? Gibt es Ausnahmen?
Unter UNIX dachte ich, wenn ein übergeordneter Prozess verschwindet, dass alle untergeordneten Prozesse init als übergeordneten zurücksetzen. Ist das nicht immer richtig? Gibt es Ausnahmen?
Antworten:
Verschieben Sie meinen Kommentar auf eine Antwort .... Ich glaube nicht, dass es Ausnahmen gibt.
Dabei wurde Folgendes festgestellt: "Manchmal wird der übergeordnete Prozess beendet, bevor sein untergeordneter Prozess beendet wird. In diesem Fall wird der" übergeordnete aller Prozesse " init-Prozess zur neuen PPID (übergeordnete Prozess-ID). Manchmal werden diese Prozesse als verwaister Prozess bezeichnet." Quelle
Ähnliches wird in IBMs Blog beschrieben : "Der Elternteil stirbt oder wird vor dem Kind getötet. Im obigen Szenario wird der Kindprozess zum verwaisten Prozess (da er seinen Elternteil verloren hat). Unter Linux wird der initProzess zur Rettung des verwaiste Prozesse und adoptiert sie. Das bedeutet, nachdem ein Kind seinen Elternteil verloren hat, wird der initProzess sein neuer Elternprozess. "
Drei Antworten aus dem Jahr 2014 besagen, dass der Prozess in Unices und Linux repariert wird, um ausnahmslos die Nummer 1 zu verarbeiten. Drei falsche Antworten. ☺
Wie der SUS in einer der anderen Antworten zitiert, wird der übergeordnete Prozess verwaister Kinder auf einen implementierungsdefinierten Prozess festgelegt . Cristian Ciupitu konsultiert zu Recht die Linux-Dokumentation, um herauszufinden, was die Implementierung definiert. Aber er wird durch diese Dokumentation in die Irre geführt, die inkonsistent und nicht aktuell ist.
Zwei Jahre bevor diese drei Antworten geschrieben wurden und schnell bis vor drei Jahren, als diese Antwort zum ersten Mal geschrieben wurde, wurde der Linux-Kernel geändert. Die Systementwickler haben die Möglichkeit hinzugefügt, dass sich Prozesse als "Subreaper" einrichten können. Ab Linux 3.4 können Prozesse den prctl()Systemaufruf mit der PR_SET_CHILD_SUBREAPEROption ausgeben. Infolgedessen werden sie, nicht Prozess Nr. 1, zum übergeordneten Element eines verwaisten Nachfolgeprozesses. Die Manpage fürprctl() ist auf dem neuesten Stand, aber andere Manpages wurden nicht auf den neuesten Stand gebracht und konsistent gemacht.
In Version 10.2 hat FreeBSD die gleichen Fähigkeiten erlangt und seinen bestehenden procctl()Systemaufruf um PROC_REAP_ACQUIREund PROC_REAP_RELEASE-Optionen erweitert. Es hat diesen Mechanismus von DragonFly BSD übernommen. welches es in der Version 4.2 erlangte, ursprünglich benannt, reapctl()aber während der Entwicklung umbenannt in procctl().
Unter Linux, FreeBSD / PC-BSD und DragonFly BSD wird der übergeordnete Prozess verwaister Kinder auf den nächsten Vorgängerprozess des Kindes festgelegt, das als Subreaper oder als Prozess 1 markiert ist wenn es keinen Vorfahren-Subreaper-Prozess gibt. Verschiedene Daemon-Überwachungsprogramme - darunter systemd (dasjenige, dessen Entwickler dies in erster Linie in den Linux-Kernel geschrieben haben), upstart und nosh service-manager- nutzen dies bereits.
Wenn ein solcher Daemon Supervisor nicht # 1 verarbeiten, und es erzeugt einen Dienst wie eine interaktive Login - Sitzung, und in dieser Sitzung tut das (ziemlich verbohrt) Trick zu versuchen , zu „daemonize“ durch Doppelklick fork()ing , dann jemandes Prozess wird landen als Kind des Daemon-Supervisors, nicht als Kind von Prozess 1. Es ist natürlich ein grundlegender Fehler, davon auszugehen, dass Dämonen direkt in Anmeldesitzungen erzeugt werden können. Aber das ist eine andere Antwort.
procctl(). DragonFly BSD-Handbuchseiten. § 2.Laut der exitManpage von The Single UNIX® Specification, Version 2:
Die übergeordnete Prozess-ID aller vorhandenen untergeordneten Prozesse und Zombie-Prozesse des aufrufenden Prozesses wird auf die Prozess-ID eines implementierungsabhängigen Systemprozesses festgelegt. Das heißt, diese Prozesse werden von einem speziellen Systemprozess vererbt.
Für die meisten Unix-Varianten ist dieser spezielle Prozess init(PID 1).
Die Linux- wait(2)Manpage bestätigt dies:
Wenn ein übergeordneter Prozess beendet wird, werden seine "Zombie" -Kinder (falls vorhanden) von init (8) übernommen, das automatisch wartet, um die Zombies zu entfernen.
Die Manpages zu FreeBSD wait(2), NetBSD wait(2), OpenBSD wait(2)und Mac OS X wait(2)bestätigen dies ebenfalls:
Wenn ein übergeordneter Prozess beendet wird, ohne darauf zu warten, dass alle untergeordneten Prozesse beendet werden, wird den verbleibenden untergeordneten Prozessen die ID des übergeordneten Prozesses 1 (die Init-Prozess-ID) zugewiesen.
Die Oracle Solaris 11.1- wait(3C)Manpage bestätigt dies ebenfalls:
Wenn ein übergeordneter Prozess beendet wird, ohne auf die Beendigung seiner untergeordneten Prozesse zu warten, wird die übergeordnete Prozess-ID jedes untergeordneten Prozesses auf 1 gesetzt, wobei der Initialisierungsprozess die untergeordneten Prozesse übernimmt. sehen
Intro(2).
Das glaube ich nicht. Es geht immer zum Init-Prozess.