Genau genommen hat die Doppelgabel nichts damit zu tun, den Dämon als Kind von neu zu erziehen init. Alles, was notwendig ist, um das Kind wieder zu erziehen, ist, dass das Elternteil beendet werden muss. Dies kann mit nur einer Gabel erfolgen. Wenn Sie einen Double-Fork alleine ausführen, wird der Daemon-Prozess nicht erneut übergeordnet init. Das übergeordnete Element des Dämons muss beendet werden . Mit anderen Worten, das übergeordnete Element wird immer beendet, wenn ein geeigneter Dämon gegabelt wird, sodass der Dämonprozess erneut übergeordnet wird init.
Warum also die Doppelgabel? POSIX.1-2008 Abschnitt 11.1.3, " Das steuernde Terminal ", enthält die Antwort (Hervorhebung hinzugefügt):
Das steuernde Terminal für eine Sitzung wird vom Sitzungsleiter auf implementierungsdefinierte Weise zugewiesen . Wenn ein Sitzungsleiter kein steuerndes Terminal hat und eine Terminalgerätedatei öffnet, die noch keiner Sitzung zugeordnet ist, ohne die O_NOCTTYOption zu verwenden (siehe open()), wird durch die Implementierung definiert, ob das Terminal zum steuernden Terminal des Sitzungsleiters wird. Wenn ein Prozess, der kein Sitzungsleiter ist, eine Terminaldatei öffnet oder die O_NOCTTYOption verwendet wird open(), wird dieses Terminal nicht zum steuernden Terminal des aufrufenden Prozesses .
Dies sagt uns, dass, wenn ein Daemon-Prozess so etwas tut ...
int fd = open("/dev/console", O_RDWR);
... dann wird der Daemon - Prozess könnte erwerben /dev/consoleals Steueranschluss, je nachdem , ob der Daemon - Prozess ist ein Session - Leiter, und in Abhängigkeit von der Systemimplementierung. Das Programm kann garantieren, dass der obige Aufruf kein steuerndes Terminal erhält, wenn das Programm zuerst sicherstellt, dass es kein Sitzungsleiter ist.
Normalerweise wird beim Starten eines Dämons setsid(vom untergeordneten Prozess nach dem Aufruf fork) aufgerufen , um den Dämon von seinem steuernden Terminal zu trennen. Aufrufen setsidbedeutet jedoch auch, dass der aufrufende Prozess der Sitzungsleiter der neuen Sitzung ist, wodurch die Möglichkeit offen bleibt, dass der Dämon ein steuerndes Terminal erneut abrufen kann. Die Double-Fork-Technik stellt sicher, dass der Daemon-Prozess nicht der Sitzungsleiter ist, wodurch garantiert wird, dass ein Aufruf von open, wie im obigen Beispiel, nicht dazu führt, dass der Daemon-Prozess ein steuerndes Terminal erneut erhält.
Die Doppelgabeltechnik ist etwas paranoid. Dies ist möglicherweise nicht erforderlich, wenn Sie wissen, dass der Dämon niemals eine Endgerätedatei öffnet. Auf einigen Systemen ist dies möglicherweise auch dann nicht erforderlich, wenn der Dämon eine Endgerätedatei öffnet, da dieses Verhalten durch die Implementierung definiert ist. Eine nicht implementierungsdefinierte Sache ist jedoch, dass nur ein Sitzungsleiter das steuernde Terminal zuweisen kann. Wenn ein Prozess kein Sitzungsleiter ist, kann er kein steuerndes Terminal zuweisen. Wenn Sie also paranoid sein möchten und sicher sein möchten, dass der Daemon-Prozess unabhängig von implementierungsdefinierten Besonderheiten nicht versehentlich ein steuerndes Terminal erwerben kann, ist die Double-Fork-Technik unerlässlich.