Follow-up Comment #5, bug #25089 (project screen): Hi Amadeusz,
[comment #4 comment #4:] > from quick look I would say that WNOHANG in waitpid() looks suspicious: > https://git.savannah.gnu.org/cgit/screen.git/tree/src/screen.c?h=screen-v4#n1495 > > Can you try removing it and see if it still happens? Bingo! This indeed seems to have solved the issue. At least I can no more reproduce it as soon as I close all my screen session, install the patched version (via patched Debian package) and try to reproduce it again. For reproducing, I start a screen session with a lot of windows (87× the line "screen" in my .screenrc for testing purposes, around 30 probably already suffice), then wait until all shells have properly started up, then I do C-a C-p until I'm at approximately window 52. If I then press C-d inside a shell to close one or more of them, with the unpatched version I get as many zombie process as I closed windows. They vanish all at once when I have close the last shell inside the screen session together with the session. And the patched version works as expected, no zombie processes. After testing with the patched version, I closed my screen session, installed the unpatched screen version again, and I was able to reproduce the issue immediately again. JFTR: this is the patch I applied: --- a/screen.c +++ b/screen.c @@ -1492,7 +1492,7 @@ if (!wstat_valid && p->w_pid > 0) { /* EOF on file descriptor. The process is probably also dead. * try a waitpid */ - if (waitpid(p->w_pid, &wstat, WNOHANG | WUNTRACED) == p->w_pid) { + if (waitpid(p->w_pid, &wstat, WUNTRACED) == p->w_pid) { p->w_pid = 0; wstat_valid = 1; } > You can also try building screen 4.7.0, it should do better system detection now, so maybe it gets fixed by that. Didn't change with the screen package from Debian Unstable/Testing (4.7.0-1) built and installed on Debian 10 Buster. So I applied the above patch to the 4.7.0-1 Debian package, too, and the issue was gone, too. We're now running the patched 4.6.2-3 in production. So far my coworker couldn't reproduce the issue instantly, but then again, he never tried to reproduce it on purpose before. (Just I did.) _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?25089> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/