Change Details

The usual way of handling process exit exit in capsicum(4) mode is by using process descriptors (pdfork(2)) instead of the traditional fork(2)/wait4(2) API. But most apps hadn't been converted this way, and many cannot because the wait is hidden behind a library APIs that revolve around PID numbers and not descriptors; GLib's g_spawn_check_wait_status(3) is one example. Thus, provide backwards compatibility by allowing the wait(2) family of functions in Capsicum mode, except for child processes created by pdfork(2). One practical result is that with this patch, a capsicated irssi(1) is no longer leaving zombies around.

The usual way of handling process exit exit in capsicum(4) mode is by using process descriptors (pdfork(2)) instead of the traditional fork(2)/wait4(2) API. But most apps hadn't been converted this way, and many cannot because the wait is hidden behind a library APIs that revolve around PID numbers and not descriptors; GLib's g_spawn_check_wait_status(3) is one example. Thus, provide backwards compatibility by allowing the wait(2) family of functions in Capsicum mode, except for child processes created by pdfork(2). One practical result is that with this patch, a capsicated irssi(1) is no longer leaving zombies around. Sponsored by: Innovate UK

The usual way of handling process exit exit in capsicum(4) mode is by using process descriptors (pdfork(2)) instead of the traditional fork(2)/wait4(2) API. But most apps hadn't been converted this way, and many cannot because the wait is hidden behind a library APIs that revolve around PID numbers and not descriptors; GLib's g_spawn_check_wait_status(3) is one example. Thus, provide backwards compatibility by allowing the wait(2) family of functions in Capsicum mode, except for child processes created by pdfork(2). One practical result is that with this patch, a capsicated irssi(1) is no longer leaving zombies around. Sponsored by: Innovate UK