Follow-up Comment #24, bug #25089 (project screen):
Hi Alex,
[comment #23 comment #23:]
> Maybe I'm wrong, but I think Amadeusz uses gentoo.
> Anyway...
>
> Can someone reproduce this issue on _NOT_Debian_ system?
> Because I also CAN NOT reproduce this problem (tested on openSUSE and
OpenBSD).
Hint: The original submission was on Mandriva:
[comment #0 original submission:]
> It looks like some sort of a race condition, because when I tried to strace
the SCREEN process, it would correctly wait() and reclaim the process (in
fact, all of the zombies were reclaimed). Also, my computer is quite slow:
>
> model name : Pentium II (Klamath)
> cpu MHz : 233.284
>
> Other useful info:
> Linux 2.6.27.8 (vanilla)
> Screen version 4.00.03 (FAU) 23-Oct-06 (from Mandriva 2009.0)
So far this issue only showed up on VMs (with Vincent and me) or on very slow
machines (original submission). I so far had only a single VMware ESX based VM
running Debian 10 Buster (Screen 4.6.2) on which I could reproduce despite I
have dozens of other machines with the same OS and Screen version.
It doesn't seem to depend on the OS, so far it seems to depend on two things:
a) using libutempter (a compile time decision by the configure script), and
b) using a slow computer or a VM.
The exact part which "needs" to be slow on a host to trigger the race
condition or why it shows up especially on VMs is though unclear to me. I was
so far unable to reproduce this on neither a Xen VM nor on a KVM (ProxMox)
based VM nor on real hardware.
Today I managed to find a second VMware ESX based VM running Debian 11 (sorry
:-) and hence Screen 4.8.0. "Screenshot" from htop:
43505 beckert 20 0 14176 5660 4472 S 0.0 0.0 0:00.06 │ │
└─ sshd: beckert@pts/0
43506 beckert 20 0 10508 6188 4420 S 0.0 0.0 0:00.07 │ │
└─ -zsh
43541 beckert 20 0 6796 3048 2804 S 0.0 0.0 0:00.00 │ │
└─ /usr/bin/screen -c /home/
43542 beckert 20 0 26436 22392 2336 S 0.0 0.1 0:00.31 │ │
└─ /usr/bin/SCREEN -c /ho
43549 beckert 20 0 10552 6224 4444 S 0.0 0.0 0:00.07 │ │
├─ /bin/zsh
43991 beckert 20 0 0 0 0 Z 0.0 0.0 0:00.06 │ │
├─ /bin/zsh
44032 beckert 20 0 10436 6184 4396 S 0.0 0.0 0:00.08 │ │
├─ /bin/zsh
44048 beckert 20 0 10436 6132 4340 S 0.0 0.0 0:00.06 │ │
├─ /bin/zsh
44064 beckert 20 0 10432 6004 4216 S 0.0 0.0 0:00.07 │ │
├─ /bin/zsh
But I had to run 5 threads of "stress-ng" (on a VM with 4 "cores") to manage
that. And I only managed it once so far (within two tries with each opening
about 80 Screen windows initially).
Oh, and JFTR: It happened with bash (my coworker) as well as with zsh (myself)
inside the screen session.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?25089>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
