Bug 196951 - Feature request: fix wait-built to allow waiting for ANY process, not just the current shell's child
Summary: Feature request: fix wait-built to allow waiting for ANY process, not just th...
Status: Closed Works As Intended
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-21 00:21 UTC by Mikhail T.
Modified: 2018-12-04 23:06 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail T. 2015-01-21 00:21:37 UTC
Historical implementation of the wait-builtin of both sh and csh relied on wait(2) (and/or friends), which only affords wait-ing for the current shell's children.

However, for some time BSD's kevent(2)'s EVFILT_PROC has allowed monitoring any visible process for the NOTE_EXIT -- a feature used by pwait(1) already.

I'd like the wait-builtin of our current base shells to be rewritten to make use of the feature -- providing the same functionality the traditional implementation offered (exit status), but allowing to watch a wider variety of processes.

One immediate application of this will allow service-scripts (such as those inside /etc/rc.d) to properly wait for the service stop before exiting or starting it again.

I'd be happy to offer the necessary patches, but wish to secure the acquiescence in principle first.
Comment 1 Mikhail T. 2015-01-21 16:03:23 UTC
Or, maybe, the wait()-function found in libc should be rewritten to use kqueue() instead of the wait() system call? That would expand the functionality of all traditional wait-users at once...
Comment 2 Mikhail T. 2015-01-22 17:45:15 UTC
Thank you very much, Jan, for your work and patience.
Comment 3 Mikhail T. 2015-01-22 17:46:11 UTC
Argh, my comment #2 was meant for an entirely different bug...
Comment 4 Jilles Tjoelker freebsd_committer 2015-04-27 12:19:24 UTC
As noted by the pwait(1) man page, pwait is not a replacement for the wait builtin, since it can wait for a process to terminate and show the exit status but cannot clean up zombies or state on the parent process. Therefore, I don't think the wait builtin should be changed -- if a script wants to wait for an unrelated process, it can use pwait.

rc.subr already uses pwait when waiting for a service to stop. This does not work optimally because pwait waits for a process to terminate, while rc.subr wants to wait for the zombie to be reaped by the parent such as init (by waiting until kill -0 PID fails).
Comment 5 Jilles Tjoelker freebsd_committer 2018-12-03 23:13:00 UTC
I don't think the wait builtin should be changed due to its dual role of waiting and reporting exit status on one hand and cleaning up associated status on the other hand.
Comment 6 Mikhail Teterin freebsd_committer 2018-12-04 01:26:07 UTC
(In reply to Jilles Tjoelker from comment #5)
>  role of waiting and reporting exit status on one hand and cleaning up associated status

I still think, sh's wait can play both roles for all processes and only the latter -- the cleaning up -- role for the sh's children. Without breaking any existing scripts...
Comment 7 Jilles Tjoelker freebsd_committer 2018-12-04 23:06:44 UTC
POSIX is clear that wait should report status 127 when a process ID is not a child of the current shell environment, and I expect that there are scripts which rely on that.

Apart from that, using the same command with the same syntax to do something quite different seems confusing.