Follow-up Comment #3, bug #25089 (project screen): A coworker ran into this on Debian 10 Buster (amd64) with Screen 4.6.2 (Debian package version 4.6.2-3) inside a (production) VM (ESX) and I was able to reproduce this under my user on the same machine.
I was able to reproduce it by opening many (like 20 or 30 or so) screen windows and then closing some of them (not the most recently created ones) again. Not every closed shell became a zombie processes, though. Looks like this at the moment: → ps auxwwwf | egrep 'Z|defunct|SCREEN' | fgrep -v grep USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND usera 32453 0.0 0.7 23776 15320 ? Ss Sep11 17:09 SCREEN usera 22527 0.0 0.0 0 0 ? Zs Oct07 0:00 \_ [bash] <defunct> usera 17308 0.0 0.0 0 0 ? Zs Oct08 0:00 \_ [bash] <defunct> userb 17774 0.0 0.6 20440 13972 ? Ss Oct09 0:08 SCREEN userb 17876 0.0 0.0 0 0 ? Zs Oct09 0:00 \_ [zsh] <defunct> userb 17902 0.0 0.0 0 0 ? Zs Oct09 0:00 \_ [zsh] <defunct> userb 17927 0.0 0.0 0 0 ? Zs Oct09 0:00 \_ [zsh] <defunct> userb 18124 0.0 0.0 0 0 ? Zs Oct09 0:00 \_ [zsh] <defunct> userb 18150 0.0 0.0 0 0 ? Zs Oct09 0:00 \_ [zsh] <defunct> userb 18174 0.0 0.0 0 0 ? Zs Oct09 0:00 \_ [zsh] <defunct> userb 20071 0.0 0.0 0 0 ? Zs Oct09 0:00 \_ [zsh] <defunct> userb 20104 0.0 0.0 0 0 ? Zs Oct09 0:00 \_ [zsh] <defunct> userb 20137 0.0 0.0 0 0 ? Zs Oct09 0:00 \_ [zsh] <defunct> Those process zombies have no according screen window anymore, i.e. are not "screen zombie windows". From the user perspective it seems as if the according shell has exited as expected and the according screen window has been closed. Maybe also worth to note is that these zombies process are not just there for a few minutes and then get cleaned up. Most of them (but not all) stay for at least days, if not until I exit the screen session. I though wasn't yet able to reproduce it on any other machine, neither with the same Debian release, the same Debian screen package (but on real hardware). So I'm still unsure what actually triggers this issue, but it only seems to surface under specific conditions, but it's still unclear under which conditions. "usera" has rather short and not fancy .screenrc file: → cat ~usera/.screenrc autodetach on hardstatus alwayslastline "%{+b dr}${USER}@%H: %n %t | %w | %l | %c:%s" startup_message off screen 0 And userb has no .screenrc at all on this host. The relevant parts of the /etc/screenrc present on that system (actually Debian's default /etc/screenrc) are: → egrep -v '^$|^#' /etc/screenrc deflogin on vbell on vbell_msg " Wuff ---- Wuff!! " defscrollback 1024 bind ^k bind ^\ bind \\ quit bind K kill bind I login on bind O login off bind } history termcapinfo vt100 dl=5\E[M hardstatus off termcapinfo xterm*|rxvt*|kterm*|Eterm* hs:ts=\E]0;:fs=\007:ds=\E]0;\007 hardstatus string "%h%? users: %u%?" termcapinfo xterm*|linux*|rxvt*|Eterm* OP termcapinfo xterm 'is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l' defnonblock 5 It also seems to be independent of the login shell. My coworker uses bash, I use zsh, and the issue is present with both. I also wondered what this box might have in common with the original reporter's box, but the only very vague connection is that a VM might be also considered a "slow" machine. So I also tried it on another, less potent VM (Xen this time) with Debian 10 Buster amd64, but wasn't able to reproduce this issue there either. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?25089> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/