☰

Wer führt eine Fork durch, wenn unter Linux doppelt auf die Anwendungen geklickt wird?

tag-icon • tag-icon linux exec forking
Wer führt eine Fork durch, wenn unter Linux doppelt auf die Anwendungen geklickt wird?

Ich weiß also, wenn ich in der Shell eine ausführbare Datei ausführe, verzweigt die Shell sie in einen untergeordneten Prozess und führt später Execs aus, um den Programm- und Datenspeicher meiner ausführbaren Datei abzurufen. Wenn meine Shell jetzt geschlossen/beendet wird, werden auch alle zugehörigen untergeordneten Prozesse beendet.

Ich habe gelesen, dass in Linux jeder Prozess über fork() exec() erstellt wird. Ich bin neugierig und habe mich gefragt, welcher Prozess forks() exec() ausführt, wenn eine Anwendung durch Doppelklicken auf das Symbol gestartet wird. Ich verstehe, dass es sich um einen Betriebssystemprozess handelt. Ich habe mich gefragt, welcher

Danke schön!

Antwort habe es zu /sbin/upstart zurückverfolgt

Antwort1

Zunächst einmal ein bisschenTerminologie.

Eine ausführbare Datei ist eine einfache Datei in Ihrem System. Ein Prozess ist die Kurzform, die das in einer ausführbaren Datei eingebettete Programm ausführt.

Sie haben Recht bezüglich derArt und Weise, wie eine ausführbare Datei gestartet wird:

  1. Der übergeordnete Prozess (bereits lebendig)forks selbst, was von diesem Punkt aus zu zwei Ausführungsflüssen führt. Einer befindet sich im übergeordneten Prozess und einer in einem neuen Prozess.
  2. Der neue (Kind-)Prozess schaltet sich selbst aus, um das Programm der auszuführenden ausführbaren Datei auszuführen. Dies geschieht mithilfe einesSystemaufrufdesexecFamilie.

Am Beispiel einer grafischen Benutzeroberfläche, auf der Sie auf das Symbol einer ausführbaren Datei doppelklicken, wird Ihre ausführbare Datei aus dem Prozess abgezweigt, der das angeklickte Symbol anzeigt, und zwar im Wesentlichen mit diesem Quellcode:

const char *exe_path = taken_from_icon();
int pid = fork();
if(pid == 0)
{
    // I am the new child
    execl(exe_path, exe_path, NULL);
    // exec only return in case of failure
    exit(EXIT_FAILURE);
}
// I am the graphical interface,
// Continue and wait for another clic

Aber dieTod und Elternschaftdes Kindes ist nicht genau so, wie Sie sagen.

Grundsätzlich ist der Kindprozess – und zwar solange der übergeordnete Prozess noch aktiv ist – das Kind seines Vaters (ja!). Seine PPID (Parent Process ID) ist auf den noch aktiven Prozess eingestellt, der ihn abgezweigt hat.

Die Dinge ändern sich, wenn der übergeordnete Prozess beendet wird. Der untergeordnete Prozess lebt weiter, aber seine PPID wird auf einen noch aktiven übergeordneten Prozess gesetzt. Es gibt immer einen, da initder Prozess nie beendet wird.

Dass Shell-Kinder sterben, wenn die Shell selbst stirbt, ist etwas Besonderes. Ich sehe dafür zwei Gründe:

  • Erstens: Eine Shell pflegt normalerweise eine Liste der PIDs, die sie geforkt hat. Und wenn die Shell stirbt, werden sie alle gelöscht. Große Shells haben einen disownintegrierten Befehl, um ein Kind aus dieser Liste zu entfernen und es am Leben zu lassen, wenn die Shell stirbt. SieheBash-Manpage:

    Die Shell wird standardmäßig beendet, wenn ein SIGHUP empfangen wird. Vor dem Beenden sendet eine interaktive Shell das SIGHUP erneut an alle laufenden oder gestoppten Jobs. An gestoppte Jobs wird SIGCONT gesendet, um sicherzustellen, dass sie das SIGHUP empfangen. Um zu verhindern, dass die Shell das Signal an einen bestimmten Job sendet, sollte dieser mit dem integrierten Befehl disown (siehe unten „SHELL BUILTIN COMMANDS“) aus der Jobtabelle entfernt oder mit disown -h so markiert werden, dass er kein SIGHUP empfängt.

  • Zweitens: Shell-Kinder haben normalerweise ihre stdin, stdout und stderr über Pipes mit der Shell selbst verbunden. Wenn die Shell aufhört, die stdout-Datei des Kindes zu verwenden (oft um sie auszudrucken) oder ihr Pipe-Ende schließt, kann es beim Schreiben in die stdout-Datei des Kindes zu Fehlern kommen, die es blockieren oder beenden können.

verwandte Informationen