Date: Thu, 19 Nov 2020 03:41:45 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 251227] setpgid sometimes returns ESRCH instead of EACCES Message-ID: <bug-251227-227-xwGyhZB7FM@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-251227-227@https.bugs.freebsd.org/bugzilla/> References: <bug-251227-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D251227 --- Comment #5 from Mahmoud Al-Qudsi <mqudsi@neosmart.net> --- Thanks for bringing my attention to the approach taken by sh - it made me realize what I'd missed. So you're right, there's no broken job control her= e. This is a real issue: > [..] prevents a subsequent process in the same job from getting access to= a > shell that was assigned over to the newly minted pgrp that now contains o= nly > zombies but it doesn't apply to FreeBSD, which is why sh can get away with ignoring= any setpgid failures. (Interestingly, tcsh handles this situation by swapping p= grps in the middle of a single job invocation.) It turns out that while FreeBSD does not consider zombie processes as valid targets of a setpgid(2) call, it *does* keep their pgrp around and permits other processes to join the pgrp even if it only contains zombies. While the original issue persists and setpgid(zombie_pid, zombie_pid) calls fail with ESRCH instead of the expected EACCES, as you say, this is trivially handled if you have any degree of confidence that you are specifying a target proce= ss that is or was a valid child pid from the same session... and (more tenuous= ly) assuming you know this is the behavior on at least some of the platforms you are targeting. It's not the end of the world by any means, but I would argue that the consideration of zombie child processes should be an everywhere or nowhere = at all type of thing (and this is where my assumption of broken job control ca= me from). e.g. Linux considers zombie processes in setpgid calls (only to determine the error code) and lets new processes join pgrps that contain only zombies, whereas some kernels (e.g. WSLv1 up until recently) don't consider zombies = at all and reclaim pgrps as soon as the last process in it exits (before it's reaped). That aside, I'm assuming we can all agree it would be great for the man pag= es to clarify the behavior when it comes to zombie procs. Are you open to a patch? Thanks! --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-251227-227-xwGyhZB7FM>