Feature #11828
open
pwait(1) should have feature to avoid its own ptree
0%
Description
pwait(1) can sometimes accidentally get its own PID or the PID of one of its ancestral processes as an argument, which will in effect cause pwait to never exit. (Using output of `pgrep -f` can sometimes cause this.) Avoiding this situation is possible, but because of the overhead involved, it should be optional. Perhaps the -P (for Paranoid) flag could be employed?
Basically, if specified, pwait would call getpid() for itself, and then use ptree(1)-like ppid chasing until there are no more ppids. Then each argument would be compared against the list of ppids, and any matches would be ignored (and perhaps reported if -v were engaged).
IMHO: This would be a good nontrivial first bugfix for a motivated new-to-illumos-contributions person.
Related issues
Updated by Joshua M. Clulow over 3 years ago
The overhead of getpid() is negligible, and the semantics of pwait waiting on itself will never work out, so I don't think I'd make that optional.
With respect to pwait acting on parents, I can imagine a -- perhaps contrived! -- scenario where you're watching some ancestor process which will terminate prior to the thing waiting for ptree. I think that regardless of the overhead (which I don't think would actually be that large) we have to make that behaviour optional either way.
Updated by Spencer Evans-Cole about 1 year ago
- Assignee set to Spencer Evans-Cole
Updated by Dan McDonald about 1 year ago
I am splitting this bug into two. This bug will remain as-is, and the new bug will focus on the more-of-a-bugfix not waiting on pwait's own pid. For now Spencer will be assigned to both, but he may wish to remove himself from this one.
Updated by Dan McDonald about 1 year ago
- Blocked by Bug #14592: pwait(1) should never wait on its own PID added