screen-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[screen-devel] [bug #25089] screen produces zombies


From: Axel Beckert
Subject: [screen-devel] [bug #25089] screen produces zombies
Date: Wed, 2 Feb 2022 15:19:09 -0500 (EST)

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]