1 .\" Hey Emacs! This file is -*- nroff -*- source.
3 .\" Copyright (c) 1993 by Thomas Koenig <ig25@rz.uni-karlsruhe.de>
4 .\" and Copyright (c) 2004 by Michael Kerrisk <mtk.manpages@gmail.com>
6 .\" Permission is granted to make and distribute verbatim copies of this
7 .\" manual provided the copyright notice and this permission notice are
8 .\" preserved on all copies.
10 .\" Permission is granted to copy and distribute modified versions of this
11 .\" manual under the conditions for verbatim copying, provided that the
12 .\" entire resulting derived work is distributed under the terms of a
13 .\" permission notice identical to this one.
15 .\" Since the Linux kernel and libraries are constantly changing, this
16 .\" manual page may be incorrect or out-of-date. The author(s) assume no
17 .\" responsibility for errors or omissions, or for damages resulting from
18 .\" the use of the information contained herein. The author(s) may not
19 .\" have taken the same level of care in the production of this manual,
20 .\" which is licensed free of charge, as they might when working
23 .\" Formatted or processed versions of this manual, if unaccompanied by
24 .\" the source, must acknowledge the copyright and authors of this work.
27 .\" Modified Sat Jul 24 13:30:06 1993 by Rik Faith <faith@cs.unc.edu>
28 .\" Modified Sun Aug 21 17:42:42 1994 by Rik Faith <faith@cs.unc.edu>
29 .\" (Thanks to Koen Holtman <koen@win.tue.nl>)
30 .\" Modified Wed May 17 15:54:12 1995 by Rik Faith <faith@cs.unc.edu>
31 .\" To remove *'s from status in macros (Thanks to Michael Shields).
32 .\" Modified as suggested by Nick Duffek <nsd@bbc.com>, aeb, 960426
33 .\" Modified Mon Jun 23 14:09:52 1997 by aeb - add EINTR.
34 .\" Modified Thu Nov 26 02:12:45 1998 by aeb - add SIGCHLD stuff.
35 .\" Modified Mon Jul 24 21:37:38 2000 by David A. Wheeler
36 .\" <dwheeler@dwheeler.com> - noted thread issues.
37 .\" Modified 26 Jun 01 by Michael Kerrisk
38 .\" Added __WCLONE, __WALL, and __WNOTHREAD descriptions
39 .\" Modified 2001-09-25, aeb
40 .\" Modified 26 Jun 01 by Michael Kerrisk, <mtk.manpages@gmail.com>
41 .\" Updated notes on setting disposition of SIGCHLD to SIG_IGN
43 .\" Added waitid(2); added WCONTINUED and WIFCONTINUED()
44 .\" Added text on SA_NOCLDSTOP
45 .\" Updated discussion of SA_NOCLDWAIT to reflect 2.6 behavior
46 .\" Much other text rewritten
47 .\" 2005-05-10, mtk, __W* flags can't be used with waitid()
48 .\" 2008-07-04, mtk, removed erroneous text about SA_NOCLDSTOP
50 .TH WAIT 2 2009-04-21 "Linux" "Linux Programmer's Manual"
52 wait, waitpid, waitid \- wait for process to change state
54 .B #include <sys/types.h>
56 .B #include <sys/wait.h>
58 .BI "pid_t wait(int *" "status" );
60 .BI "pid_t waitpid(pid_t " pid ", int *" status ", int " options );
62 .BI "int waitid(idtype_t " idtype ", id_t " id \
63 ", siginfo_t *" infop ", int " options );
66 Feature Test Macro Requirements for glibc (see
67 .BR feature_test_macros (7)):
71 _SVID_SOURCE || _XOPEN_SOURCE
73 All of these system calls are used to wait for state changes
74 in a child of the calling process, and obtain information
75 about the child whose state has changed.
76 A state change is considered to be: the child terminated;
77 the child was stopped by a signal; or the child was resumed by a signal.
78 In the case of a terminated child, performing a wait allows
79 the system to release the resources associated with the child;
80 if a wait is not performed, then the terminated child remains in
81 a "zombie" state (see NOTES below).
83 If a child has already changed state, then these calls return immediately.
84 Otherwise they block until either a child changes state or
85 a signal handler interrupts the call (assuming that system calls
86 are not automatically restarted using the
90 In the remainder of this page, a child whose state has changed
91 and which has not yet been waited upon by one of these system
94 .SS "wait() and waitpid()"
97 system call suspends execution of the calling process until one of its
104 waitpid(\-1, &status, 0);
109 system call suspends execution of the calling process until a
112 argument has changed state.
115 waits only for terminated children, but this behavior is modifiable
118 argument, as described below.
124 meaning wait for any child process whose process group ID is
125 equal to the absolute value of
128 meaning wait for any child process.
130 meaning wait for any child process whose process group ID is
131 equal to that of the calling process.
133 meaning wait for the child whose process ID is equal to the
139 is an OR of zero or more of the following constants:
142 return immediately if no child has exited.
145 also return if a child has stopped
150 children which have stopped is provided
151 even if this option is not specified.
153 .BR WCONTINUED " (since Linux 2.6.10)"
154 also return if a stopped child has been resumed by delivery of
157 (For Linux-only options, see below.)
165 store status information in the \fIint\fP to which it points.
166 This integer can be inspected with the following macros (which
167 take the integer itself as an argument, not a pointer to it,
173 .BI WIFEXITED( status )
174 returns true if the child terminated normally, that is,
179 or by returning from main().
181 .BI WEXITSTATUS( status )
182 returns the exit status of the child.
183 This consists of the least significant 8 bits of the
185 argument that the child specified in a call to
189 or as the argument for a return statement in main().
190 This macro should only be employed if
194 .BI WIFSIGNALED( status )
195 returns true if the child process was terminated by a signal.
197 .BI WTERMSIG( status )
198 returns the number of the signal that caused the child process to
200 This macro should only be employed if
204 .BI WCOREDUMP( status )
205 returns true if the child produced a core dump.
206 This macro should only be employed if
209 This macro is not specified in POSIX.1-2001 and is not available on
210 some Unix implementations (e.g., AIX, SunOS).
211 Only use this enclosed in #ifdef WCOREDUMP ... #endif.
213 .BI WIFSTOPPED( status )
214 returns true if the child process was stopped by delivery of a signal;
215 this is only possible if the call was done using
217 or when the child is being traced (see
220 .BI WSTOPSIG( status )
221 returns the number of the signal which caused the child to stop.
222 This macro should only be employed if
226 .BI WIFCONTINUED( status )
228 returns true if the child process was resumed by delivery of
233 system call (available since Linux 2.6.9) provides more precise
234 control over which child state changes to wait for.
240 arguments select the child(ren) to wait for, as follows:
241 .IP "\fIidtype\fP == \fBP_PID\fP"
242 Wait for the child whose process ID matches
244 .IP "\fIidtype\fP == \fBP_PGID\fP"
245 Wait for any child whose process group ID matches
247 .IP "\fIidtype\fP == \fBP_ALL\fP"
252 The child state changes to wait for are specified by ORing
253 one or more of the following flags in
257 Wait for children that have terminated.
260 Wait for children that have been stopped by delivery of a signal.
263 Wait for (previously stopped) children that have been
264 resumed by delivery of
267 The following flags may additionally be ORed in
275 Leave the child in a waitable state; a later wait call
276 can be used to again retrieve the child status information.
278 Upon successful return,
280 fills in the following fields of the
282 structure pointed to by
286 The process ID of the child.
289 The real user ID of the child.
290 (This field is not set on most other implementations.)
297 Either the exit status of the child, as given to
301 or the signal that caused the child to terminate, stop, or continue.
304 field can be used to determine how to interpret this field.
312 (child killed by signal);
314 (child killed by signal, and dumped core);
316 (child stopped by signal);
318 (traced child has trapped); or
327 and there were no children in a waitable state, then
329 returns 0 immediately and
332 structure pointed to by
335 .\" POSIX.1-2001 leaves this possibility unspecified; most
336 .\" implementations (including Linux) zero out the structure
337 .\" in this case, but at at least one implementation (AIX 5.1)
338 .\" does not -- MTK Nov 04
339 To distinguish this case from that where a child was in a
340 waitable state, zero out the
342 field before the call and check for a nonzero value in this field
343 after the call returns.
346 on success, returns the process ID of the terminated child;
347 on error, \-1 is returned.
350 on success, returns the process ID of the child whose state has changed;
353 was specified and one or more child(ren) specified by
355 exist, but have not yet changed state, then 0 is returned.
356 On error, \-1 is returned.
359 returns 0 on success or
362 was specified and no child(ren) specified by
364 has yet changed state;
365 on error, \-1 is returned.
366 .\" FIXME: As reported by Vegard Nossum, if infop is NULL, then waitid()
367 .\" returns the PID of the child. Either this is a bug, or it is intended
368 .\" behavior that needs to be documented. See my Jan 2009 LKML mail
369 .\" "waitid() return value strangeness when infop is NULL".
370 Each of these calls sets
372 to an appropriate value in the case of an error.
378 The calling process does not have any unwaited-for children.
385 The process specified by
393 does not exist or is not a child of the calling process.
394 (This can happen for one's own child if the action for
398 See also the \fILinux Notes\fP section about threads.)
402 was not set and an unblocked signal or a
410 argument was invalid.
412 SVr4, 4.3BSD, POSIX.1-2001.
414 A child that terminates, but has not been waited for becomes a "zombie".
415 The kernel maintains a minimal set of information about the zombie
416 process (PID, termination status, resource usage information)
417 in order to allow the parent to later perform a wait to obtain
418 information about the child.
419 As long as a zombie is not removed from the system via a wait,
420 it will consume a slot in the kernel process table, and if
421 this table fills, it will not be possible to create further processes.
422 If a parent process terminates, then its "zombie" children (if any)
425 which automatically performs a wait to remove the zombies.
427 POSIX.1-2001 specifies that if the disposition of
437 then children that terminate do not become zombies and a call to
441 will block until all children have terminated, and then fail with
445 (The original POSIX standard left the behavior of setting
450 Note that even though the default disposition of
452 is "ignore", explicitly setting the disposition to
454 results in different treatment of zombie process children.)
455 Linux 2.6 conforms to this specification.
456 However, Linux 2.4 (and earlier) does not:
463 is being ignored, the call behaves just as though
465 were not being ignored, that is, the call blocks until the next child
466 terminates and then returns the process ID and status of that child.
468 In the Linux kernel, a kernel-scheduled thread is not a distinct
469 construct from a process.
470 Instead, a thread is simply a process
471 that is created using the Linux-unique
473 system call; other routines such as the portable
474 .BR pthread_create (3)
475 call are implemented using
477 Before Linux 2.4, a thread was just a special case of a process,
478 and as a consequence one thread could not wait on the children
479 of another thread, even when the latter belongs to the same thread group.
480 However, POSIX prescribes such functionality, and since Linux 2.4
481 a thread can, and by default will, wait on children of other threads
482 in the same thread group.
484 The following Linux-specific
486 are for use with children created using
488 they cannot be used with
493 Wait for "clone" children only.
494 If omitted then wait for "non-clone" children only.
495 (A "clone" child is one which delivers no signal, or a signal other than
497 to its parent upon termination.)
498 This option is ignored if
502 .BR __WALL " (since Linux 2.4)"
503 .\" since patch-2.3.48
504 Wait for all children, regardless of
505 type ("clone" or "non-clone").
507 .BR __WNOTHREAD " (since Linux 2.4)"
508 .\" since patch-2.4.0-test8
509 Do not wait for children of other threads in
510 the same thread group.
511 This was the default before Linux 2.4.
513 .\" fork.2 refers to this example program.
514 The following program demonstrates the use of
518 The program creates a child process.
519 If no command-line argument is supplied to the program,
520 then the child suspends its execution using
522 to allow the user to send signals to the child.
523 Otherwise, if a command-line argument is supplied,
524 then the child exits immediately,
525 using the integer supplied on the command line as the exit status.
526 The parent process executes a loop that monitors the child using
528 and uses the W*() macros described above to analyze the wait status value.
530 The following shell session demonstrates the use of the program:
537 .RB "$" " kill \-STOP 32360"
539 .RB "$" " kill \-CONT 32360"
541 .RB "$" " kill \-TERM 32360"
550 #include <sys/wait.h>
556 main(int argc, char *argv[])
567 if (cpid == 0) { /* Code executed by child */
568 printf("Child PID is %ld\\n", (long) getpid());
570 pause(); /* Wait for signals */
571 _exit(atoi(argv[1]));
573 } else { /* Code executed by parent */
575 w = waitpid(cpid, &status, WUNTRACED | WCONTINUED);
581 if (WIFEXITED(status)) {
582 printf("exited, status=%d\\n", WEXITSTATUS(status));
583 } else if (WIFSIGNALED(status)) {
584 printf("killed by signal %d\\n", WTERMSIG(status));
585 } else if (WIFSTOPPED(status)) {
586 printf("stopped by signal %d\\n", WSTOPSIG(status));
587 } else if (WIFCONTINUED(status)) {
588 printf("continued\\n");
590 } while (!WIFEXITED(status) && !WIFSIGNALED(status));
604 .BR pthread_create (3),