Provided by: manpages-de-dev_4.23.1-1_all
BEZEICHNUNG
getpid, getppid - gibt die Prozessidentifikation zurück
BIBLIOTHEK
Standard-C-Bibliothek (libc, -lc)
ÜBERSICHT
#include <unistd.h> pid_t getpid(void); pid_t getppid(void);
BESCHREIBUNG
getpid() gibt die Prozesskennung (PID) des aufrufenden Prozesses zurück. (Dies wird oft von Routinen benutzt, die einen eindeutigen Namen einer temporären Datei erzeugen.) getppid() liefert die Prozesskennung des Elternprozesses des aufrufenden Prozesses zurück. Dies wird entweider die Kennung des Prozesses, der diesen Prozess mittels fork() erstellte, oder, falls dieser Prozess bereits beendet wurde, die Kennung des Prozesses, an der neue Elternprozess für diesen Prozess geworden ist (entweder init(1) oder ein mittels der Aktion prctl(2) PR_SET_CHILD_SUBREAPER definierter »subreaper«-Prozess).
FEHLER
Diese Funktionen sind immer erfolgreich.
VERSIONEN
Unter Alpha wird statt eines Paars von getpid()- und getppid()-Systemaufrufen ein einzelner Systemaufruf getxpid() bereitgestellt, der ein Paar von realen und effektiven PIDs bereitstellt. Die Glibc-Wrapper-Funktionen getpid() und getppid() gehen damit transparent um. Siehe syscall(2) für Details im Hinblick auf Registerabbildungen.
STANDARDS
POSIX.1-2008.
GESCHICHTE
POSIX.1-2001, 4.3BSD, SVr4. Unterschiede C-Bibliothek/Kernel Von Glibc 2.3.4 bis einschließlich 2.24 speicherte die Glibc-Wrapper-Funktion für getpid() PIDs temporär, um zusätzliche Systemaufrufe zu vermeiden, wenn ein Prozess getpid() mehrmals aufruft. Normalerweise war dieses Zwischenspeichern nicht sichtbar, aber das korrekte Funktionieren beruhte auf der Unterstützung in den Wrapper-Funktionen für fork(2), vfork(2) und clone(2): Wenn eine Anwendung die Glibc-Wrapper für diese Systemaufrufe durch Benutzung von syscall(2) umging, dann würde ein Aufruf von getpid() im Kindprozess den falschen Wert zurückliefern (um es zu präzisieren: Er wird die PID des Elternprozesses zurückgeben). Zusätzlich gab es Fälle, bei dem getpid() den falschen Wert sogar dann zurückgab, wenn clone(2) über die Glibc-Wrapper-Funktion aufgerufen wurde. (Für die Besprechung eines solchen Falles siehe FEHLER in clone(2).) Desweiteren war die Komplexität des Zwischenspeichercodes über die Jahre eine Quelle mehrerer Fehler innerhalb der Glibc. Aufgrund der vorgenannten Probleme ist der PID-Zwischenspeichercode seit Glibc 2.25 entfernt; Aufrufe von getpid() lösen immer den tatsächlichen Systemaufruf aus, statt einen zwischengespeicherten Wert zurückzuliefern.
ANMERKUNGEN
Falls sich der Elternprozess des aufrufenden Prozesses in einem anderen PID-Namensraum befindet (siehe pid_namespaces(7)), gibt getppid() 0 zurück. Aus der Sicht des Kernels ist die PID (die sich alle Threads in einem Multithreaded-Prozess teilen) manchmal auch als Thread-Gruppenkennung (TGID) bekannt. Dies steht im Gegensatz zu der Kernel Thread ID (TID), die für jeden Thread eindeutig ist. Für weitere Details siehe gettid(2) und die Diskussion des Schalters CLONE_THREAD in clone(2).
SIEHE AUCH
clone(2), fork(2), gettid(2), kill(2), exec(3), mkstemp(3), tempnam(3), tmpfile(3), tmpnam(3), credentials(7), pid_namespaces(7)
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Stefan Janke <gonzo@burg.studfb.unibw-muenchen.de>, Chris Leick <c.leick@vollbio.de>, Mario Blättermann <mario.blaettermann@gmail.com> und Helge Kreutzmann <debian@helgefjell.de> erstellt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copyright- Bedingungen. Es wird KEINE HAFTUNG übernommen. Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E- Mail an die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.