fork

FORK(2)                    Linux-Programmierhandbuch                   FORK(2)



BEZEICHNUNG
       fork - erzeugt einen Kindprozess

ÃBERSICHT
       #include <sys/types.h>
       #include <unistd.h>

       pid_t fork(void);

BESCHREIBUNG
       fork() erzeugt einen neuen Prozess, indem der aufrufende Prozess
       dupliziert wird. Der neue Prozess wird als das Kind bezeichnet. Der
       aufrufende Prozess wird als Elternprozess bezeichnet.

       Der Kind- und der Elternprozess laufen in separaten Speicherbereichen.
       Zum Zeitpunkt von fork() haben beide Speicherbereiche den gleichen
       Inhalt. Speicherschreibvorgänge, Dateizuordnungen (mmap(2)) und die
       Lösung von Zuordnungen (munmap(2)) eines Prozesses beeinflussen den
       jeweiligen anderen Prozess nicht.

       Der Kindprozess ist ein exaktes Duplikat des Elternprozesses, mit
       folgenden Ausnahmen:

       *  Das Kind hat seine eigene eindeutige Prozesskennung, die mit keiner
          Kennung irgendeiner existierenden Prozessgruppe oder Sitzung
          übereinstimmt (setpgid(2)).

       *  Die Elternprozesskennung des Kindes ist die gleiche wie die
          Prozesskennung des Elternprozesses.

       *  Das Kind erbt keine Speichersperren (mlock(2), mlockall(2)) des
          Elternprozesses.

       *  Für das Kind wird die Nutzung von Prozessressourcen (getrusage(2))
          und Zähler für CPU-Zeiten (times(2)) auf null zurückgesetzt.

       *  Die Menge der für das Kind anstehenden Signale ist anfangs leer
          (sigpending(2)).

       *  Das Kind erbt keine Semaphor-Einstellungen von seinem Elternprozess
          (semop(2)).

       *  Das Kind erbt keine prozess-zugeordneten Datensatzsperren von seinem
          Elternprozess (fcntl(2)). (Allerdings erbt es offene
          Dateideskriptionssperren von fcntl(2) und flock(2)-Sperren von
          seinem Elternprozess.)

       *  Das Kind erbt keine Timer von seinem Elternprozess (setitimer(2),
          alarm(2), timer_create(2)).

       *  Das Kind erbt keine ausstehenden asynchronen E/A-Operationen von
          seinem Elternprozess (aio_read(3), aio_write(3)), auch asynchrone
          E/A-Kontexte des Elternprozesses werden nicht vererbt (siehe
          io_setup(2)).

       Die Prozessattribute in der vorstehenden Liste werden allesamt in
       POSIX.1 beschrieben. Eltern- und Kindprozess unterscheiden sich auch in
       den folgenden Linux-spezifischen Prozessattributen:

       *  Das Kind erbt keine Nachrichten über Verzeichnisänderungen
          (directory change notifications, dnotify) von seinem Elternprozess
          (siehe die Beschreibung von F_NOTIFY in fcntl(2)).

       *  Die Einstellung PR_SET_PDEATHSIG von prctl(2) wird zurückgesetzt,
          sodass das Kind kein Signal empfängt, wenn sein Elternprozess
          terminieren.

       *  Der voreingestellte Wert für den Timer-Spielraum (»timer slack«)
          wird auf den aktuellen Timer-Spielraum des Elternprozesses gesetzt.
          Siehe die Beschreibung von PR_SET_TIMERSLACK in prctl(2).

       *  Memory mappings that have been marked with the madvise(2)
          MADV_DONTFORK flag are not inherited across a fork().

       *  Speicher in dem Adressbereich, der mit dem madvise(2)-Schalter
          MADV_WIPEONFORK markiert ist, wird nach einem fork() im Kind
          genullt. (Die Einstellung MADV_WIPEONFORK verbleibt für diese
          Adressbereiche im Kind.)

       *  Das Terminierungssignal des Kindes ist immer SIGCHLD (siehe
          clone(2)).

       *  Die von ioperm(2) gesetzten Bits für Portzugriffe werden nicht an
          das Kind vererbt, stattdessen muss das Kind benötigte Bits mittels
          ioperm(2) aktivieren.

       Beachten Sie die folgenden weiteren Punkte:

       *  Der Kindprozess wird mit einem einzigen Thread erstellt â
          demjenigen, der fork aufrief. Der gesamte virtuelle Adressraum des
          Elternprozesses wird im Kind repliziert, einschlieÃlich der
          Zustände der Mutexe, Zustandsvariablen und anderer
          »pthread«-Objekte; die Verwendung von pthread_atfork(3) kann
          hilfreich sein für die Behandlung von dadurch verursachten
          Problemen.

       *  Nach einem fork() in einem Multithread-Programm kann das Kind sicher
          nur async-signal-safe-Funktionen aufrufen (siehe signal-safety(7)),
          bis es execve(2) aufruft.

       *  Das Kind erbt Kopien der Menge der offenen Dateideskriptoren des
          Elternprozesses. Jeder Deskriptor des Kindes bezieht sich auf die
          gleichen offenen Dateideskriptoren (siehe open(2)) wie der
          entsprechende Dateideskriptor in dem Elternprozess. Dies bedeutet,
          dass die beiden Dateideskriptoren die Statusschalter geöffneter
          Dateien, den Datei-Offset und signalgesteuerte E/A-Attribute (siehe
          die Beschreibung von F_SETOWN und F_SETSIG in fcntl(2)) gemeinsam
          nutzen.

       *  Das Kind erbt Kopien der Menge der Deskriptoren des Elternprozesses
          für offene Nachrichten-Warteschlangen (siehe mq_overview(7)). Jeder
          Dateideskriptor des Kindes bezieht sich auf die gleiche
          Nachrichtenwarteschlangendeskription wie der entsprechende
          Dateideskriptor in dem Elternprozess. Das bedeutet, dass die beiden
          Dateideskriptoren die gleichen Schalter (mq_flags) gemeinsam nutzen.

       *  Das Kind erbt Kopien der Menge der offenen Verzeichnis-Streams des
          Elternprozesses (siehe opendir(3)). POSIX.1 besagt, dass die
          entsprechenden Verzeichnis-Streams auf die gleiche Position zeigen
          können; unter Linux/Glibc tun sie es nicht.

RÃCKGABEWERT
       Bei Erfolg wird im Elternprozess die PID des Kindprozesses
       zurückgegeben und in dem Kind 0. Bei Fehlern wird dem Elternprozess -1
       zurückgegeben, kein Kindprozess erzeugt und errno entsprechend
       gesetzt.

FEHLER
       EAGAIN Eine systembedingte Begrenzung der Anzahl der Threads wurde
              erreicht. Es gibt eine Reihe von Begrenzungen, die diesen Fehler
              auslösen können:

              *  die weiche Ressourcenbegrenzung RLIMIT_NPROC (mittels
                 setrlimit(2) gesetzt), die die Anzahl der Prozesse und
                 Threads für eine reale Benutzerkennung begrenzt, wurde
                 erreicht;

              *  die systemweite Kernelbegrenzung der Anzahl an Prozessen und
                 Threads, /proc/sys/kernel/threads-max, wurde erreicht (siehe
                 proc(5));

              *  die maximale Anzahl an PIDs, /proc/sys/kernel/pid_max, wurde
                 erreicht (siehe proc(5));

              *  die durch den Cgroup-Controller »process number«
                 erzwungende PID-Begrenzung (pids.max) wurde erreicht.

       EAGAIN Die aufrufende Instanz agiert gemäà der
              SCHED_DEADLINE-Scheduling-Regeln und hat den Schalter
              reset-on-fork nicht gesetzt. Siehe sched(7).

       ENOMEM fork() konnte wegen Speicherknappheit die erforderlichen
              Kernel-Strukturen nicht anlegen.

       ENOMEM Es wurde versucht, einen Kindprozess in einem PID-Namensraum,
              dessen »init«-Prozess sich beendet hat, zu erstellen. Siehe
              pid_namespaces(7).

       ENOSYS fork() wird auf dieser Plattform nicht unterstützt
              (beispielsweise Hardware ohne eine Speicher-Management-Einheit).

       ERESTARTNOINTR (seit Linux 2.6.17)
              Ein Systemaufruf wurde durch ein Signal unterbrochen und wird
              neu gestartet. (Dies wird nur während einer Verfolgung sichtbar
              sein.)

KONFORM ZU
       POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD.

ANMERKUNGEN
       Unter Linux ist fork() mittels »copy-on-write«-Seiten implementiert,
       sodass der einzige Nachteil von fork() die Zeit und der Speicher ist,
       der benötigt wird, um die Page Tables des Elternprozesses zu kopieren
       und eine eindeutige Task-Struktur für das Kind anzulegen.

   Unterschiede C-Bibliothek/Kernel
       Der Glibc-Wrapper für fork() wird als Teil der
       NPTL-Threading-Implementierung bereitgestellt. Seit Version 2.3.3 der
       Glibc ruft der fork()-Wrapper nicht mehr den Kernel-Systemaufruf fork()
       auf, sondern clone(2) mit Schaltern, die das Gleiche bewirken wie der
       traditionelle Systemaufruf. (Ein Aufruf von fork() ist gleichbedeutend
       mit einem Aufruf von clone(2), bei dem für flags nur SIGCHLD angegeben
       wird.) Der Glibc-Wrapper ruft alle Fork-Handler auf, die mittels
       pthread_atfork(3) eingerichtet wurden.

BEISPIEL
       Siehe pipe(2) und wait(2).

SIEHE AUCH
       clone(2), execve(2), exit(2), setrlimit(2), unshare(2), vfork(2),
       wait(2), daemon(3), pthread_atfork(3), capabilities(7), credentials(7)

KOLOPHON
       Diese Seite ist Teil der Veröffentlichung 5.02 des Projekts
       Linux-man-pages. Eine Beschreibung des Projekts, Informationen, wie
       Fehler gemeldet werden können sowie die aktuelle Version dieser Seite
       finden sich unter https://www.kernel.org/doc/man-pages/.


ÃBERSETZUNG
       Die deutsche Ãbersetzung dieser Handbuchseite wurde von Martin Schulze
       <joey@infodrom.org>, Martin Eberhard Schauer <Martin.E.Schauer@gmx.de>,
       Holger Wansing <linux@wansing-online.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 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 <debian-l10n-
       german@lists.debian.org>.



Linux                         15. September 2017                       FORK(2)