bugGNU Screen - Bugs: bug #25089, screen produces zombies

 
 

bug #25089: screen produces zombies

Submitter:  Michal Svoboda <pht1>
Submitted:  Sun 14 Dec 2008 07:36:20 AM UTC
   
 
Category:  Program Logic Severity:  3 - Normal
Priority:  * 5 - Normal Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Release:  4.0.3
Fixed Release:  4.9.1 Planned Release:  4.9.1
Work Required:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 17 Feb 2022 01:28:37 AM UTC, comment #27: 

I applied patches to master and screen-v4 branches. Everyone are welcome to test it.

Thanks a lot.

Alexander Naumov <anaumov>
Group administrator
Thu 03 Feb 2022 02:03:49 AM UTC, comment #26: 

BTW, my VM has only one CPU core. To try to reproduce the bug on real hardware, I think that one should make everything run on one CPU core if possible.

Vincent Lefèvre <vinc17>
Thu 03 Feb 2022 01:47:30 AM UTC, comment #25: 

comment #24 :

> 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.


This is actually more complex. To reproduce the issue, the SIGCHLD needs to be received while the action has been set to SIG_DFL by libutempter, basically while the libutempter helper is running. I had noticed that reducing or disabling the compiler optimizations for screen made the zombies less likely to appear on my VM. And this probably depends very much on the hardware (e.g., on my laptop, I recently noticed that a race condition in the display manager triggered an issue only after I changed the SSD disk, just because the new SSD disk is faster).

> 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.


My VM (at Gandi) is based on Xen. And the issue is 100% reproducible.

I've just tried to reproduce the issue on my laptop by adding a "sleep(1);" after the SIGCHLD action has been set to SIG_DFL in libutempter (iface.c), but I couldn't. I suppose that the SIGCHLD arrives earlier. I don't know which stress-ng options could be used to have it delayed ("--all 1" completely freezes my machine).

Vincent Lefèvre <vinc17>
Wed 02 Feb 2022 08:19:09 PM UTC, comment #24: 

Hi Alex,

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:

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.

Axel Beckert <abe>
Wed 02 Feb 2022 05:40:04 PM UTC, comment #23: 


comment #9:

> That would be a lot easier if I could reproduce it...
>


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).

Alexander Naumov <anaumov>
Group administrator
Wed 02 Feb 2022 03:58:59 PM UTC, comment #22: 

comment #20:

> commentaire #19 :
> > I doubt that this will solve the case (completely) either because this issue already happened in Debian 9 Stretch before I enabled libutempter support in Debian in Debian 10 Buster.
>
> OK, perhaps there are different causes. But I started to see this issue only since Debian 10 buster […]. IIRC, I had never seen it before. At least my patch solves the issue due to libutempter (and the analysis was showing that libutempter was the cause).
>
> Note also that AFAIK, there have never been similar bug reports concerning Debian before Debian 10. Those who saw zombies earlier didn't necessarily run Debian.


Hrm, you've made me think. Rereading my first comment in here, I indeed wrote "Buster". I though was quite sure that I dist-upgraded that box at least once since seeing these issues. (And it still runs Buster.) I just checked the upgrade history and the upgrade from Stretch to Buster was in early Sept. 2019, the comment was a month afterwards.

So maybe what I remembered wasn't a dist-upgrade but an CVE fix like the one I mentioned — which actually was the only one, so it probably was that one. Because what I actually remembered was the thought that since I have to upgrade screen soon anyway, I'll postpone further investigation to afterwards in case it has been fixed by accident. And because that CVE was way more urgent and more important. :-)

Then again I also remember that I digged deeper into this only after quite a while experiencing this issue. I thought it might have been a year or at least several months so (which would point to Debian 9 Stretch, too), but maybe it was only a month (which would point to Debian 10 Buster only).

So I digged out the logs of our monitoring. And there's indeed a huge gap of no such issues between October 2017 and end of September 2019. And those zombies from 2017 weren't related to screen.

So thanks for pointing out that fact — you're probably right. For now I'll stick to the facts and not my vague memories. :-)


Now playing: The Hooters — All Your Zombies (SCNR)

Axel Beckert <abe>
Wed 02 Feb 2022 03:40:45 PM UTC, comment #21: 

Axel: This actually started with this bug report by a Mandriva user in 2008 (no-one else confirmed at that time). Then this became silent until you mentioned the bug in October 2019 (thus 11 years later) for Debian 10 Buster. The 11-year gap after a single report is a lot. Many things could have happened and the code has probably much changed. If this 2008 issue had a different cause, this very old bug may already have been fixed (no reports for 11 years) and we are seeing something different as of Debian 10.

Vincent Lefèvre <vinc17>
Wed 02 Feb 2022 03:12:49 PM UTC, comment #20: 

commentaire #19 :

> I doubt that this will solve the case (completely) either because this issue already happened in Debian 9 Stretch before I enabled libutempter support in Debian in Debian 10 Buster.


OK, perhaps there are different causes. But I started to see this issue only since Debian 10 buster (my Debian bug report was against 4.6.2-3+deb10u1). IIRC, I had never seen it before. At least my patch solves the issue due to libutempter (and the analysis was showing that libutempter was the cause).

Note also that AFAIK, there have never been similar bug reports concerning Debian before Debian 10. Those who saw zombies earlier didn't necessarily run Debian.

Vincent Lefèvre <vinc17>
Wed 02 Feb 2022 02:55:34 PM UTC, comment #19: 

Hi Vincent,

comment #14:

> I've found a clash between GNU Screen and libutempter (used in utmp.c): libutempter needs to execute some helper, and temporarily resets the SIGCHLD handler to the default action. If the signal from the terminated shell process arrives at this time, the handler set up by GNU Screen will not be called.


I doubt that this will solve the case (completely) either because this issue already happened in Debian 9 Stretch before I enabled libutempter support in Debian in Debian 10 Buster.

At some point in the past (when I had to deal with the CVE-2021-26937 fix in early 2021, i.e. before your Debian bug report in summer 2021) I set screen zombies to be ignored in our monitoring system. I will now reenable this monitoring check and start tracking this issue again, also by trying out your patch on that one machine where me and colleagues run into it, once we ran into it again.

Axel Beckert <abe>
Wed 02 Feb 2022 01:08:57 PM UTC, comment #18: 

This bug still occurs with screen 4.9.0, and my patch still fixes it.

Vincent Lefèvre <vinc17>
Thu 05 Aug 2021 12:01:45 PM UTC, comment #17: 

Really attaching the patch: file #51740

Vincent Lefèvre <vinc17>
Thu 05 Aug 2021 11:57:38 AM UTC, comment #16: 

I'm attaching a patch, which consists in sending SIGCHLD to oneself after calling a libutempter function (where a SIGCHLD may have been lost). This is probably the simplest and most logical solution.

I've tested it on my Debian VM with both screen 4.6.2 (Debian 10 buster) and screen 4.8.0 (future Debian 11 bullseye). It solves the problem for me with both.

Vincent Lefèvre <vinc17>
Mon 02 Aug 2021 02:22:10 PM UTC, comment #15: 

Note also that, as I've said in my Debian bug report, GotSigChld (which is modified in a signal handler) needs to be declared as volatile in order to disable some compiler optimizations (currently not affecting the code, but this might happen in the future).

I'm wondering how to fix the real issue. One knows that a SIGCHLD may have been lost by some libutempter functions called in pututslot() (defined in utmp.c). Thus pututslot() could call DoWait() directly or set GotSigChld, if this is valid. To be able to do that, one would also need to export DoWait() or GotSigChld. Alternatively, send a SIGCHLD to oneself.

Vincent Lefèvre <vinc17>
Mon 02 Aug 2021 01:56:02 PM UTC, comment #14: 

I think that the patches are wrong (they may just make the issue less likely to occur, without solving the real bug).

I've analyzed the problem in my Debian bug report
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991715
and I've found a clash between GNU Screen and libutempter (used in utmp.c): libutempter needs to execute some helper, and temporarily resets the SIGCHLD handler to the default action. If the signal from the terminated shell process arrives at this time, the handler set up by GNU Screen will not be called.

Unfortunately I could not confirm with strace as the issue is not reproducible with it (probably due to the delay caused by strace). Still, strace information suggests that this is the cause of the problem. You can find more details in my Debian bug report.

Vincent Lefèvre <vinc17>
Sun 29 Dec 2019 08:42:58 AM UTC, comment #13: 

Yay! Thanks for fixing this decade old bug.

Michal Svoboda <pht1>
Sat 28 Dec 2019 07:34:59 PM UTC, comment #12: 

The reason for this is that in the C language only some very narrow set of library functions can be invoked from the signal handler

FreeBSD sigaction(2) manpage lists them and adds:

https://www.freebsd.org/cgi/man.cgi?query=sigaction&apropos=0&sektion=2&manpath=FreeBSD+12.1-RELEASE+and+Ports&arch=default&format=html

> All functions not in the above lists are considered to be unsafe with
> respect to signals.  That is to say, the behaviour of such functions is
> undefined when they are called from a signal handler that interrupted an
> unsafe function.  In general though, signal handlers should do little
> more than set a flag; most other actions are not safe.


Therefore it was the best practice in the signal handlers only to   set the variable and deal with the actual handling later.

Marcin Cieślak <saper>
Sat 28 Dec 2019 07:23:15 PM UTC, comment #11: 

I can't find a reason, why it is done a way it is currently... as it seems to have been done this way from the beginning.

So, let's try just running SIGCHLD handler directly instead of doing scheduling with GotSigChld variable.

Let's check first if this fixes it and then I'll think further.

try3.patch in attachment

(file #48133)

Amadeusz Sławiński <amade>
Group administrator
Sat 28 Dec 2019 06:02:55 PM UTC, comment #10: 

Actually, ignore it for now, I hurried up a bit and forgot to test run it properly and screen hangs... will send better one

Amadeusz Sławiński <amade>
Group administrator
Sat 28 Dec 2019 06:00:38 PM UTC, comment #9: 

That would be a lot easier if I could reproduce it...

Anyway I suspect that with patch counter may still be decreased to early.

I attached new one, can you try with it?

(file #48132)

Amadeusz Sławiński <amade>
Group administrator
Fri 22 Nov 2019 02:59:37 PM UTC, comment #8: 

comment #7:

> As mentioned on mailing list, it is a bad solution.
> Try newly attached patch instead.
>
> (file #47810)


As mentioned on mailing list, I've done that now.
Unfortunately the new patch doesn't fix the issue.

Axel Beckert <abe>
Wed 06 Nov 2019 08:36:58 PM UTC, comment #7: 

As mentioned on mailing list, it is a bad solution.
Try newly attached patch instead.

(file #47810)

Amadeusz Sławiński <amade>
Group administrator
Wed 23 Oct 2019 12:41:20 PM UTC, comment #6: 

Hi again,

comment #5:

> 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.)


JFTR: No more sightings of screen child zombies on that VM since then. So I consider the patch to be sufficient to fix this issue.

Axel Beckert <abe>
Mon 14 Oct 2019 04:48:36 PM UTC, comment #5: 

Hi Amadeusz,

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.)

Axel Beckert <abe>
Fri 11 Oct 2019 06:04:58 PM UTC, comment #4: 

Well...
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?

You can also try building screen 4.7.0, it should do better system detection now, so maybe it gets fixed by that.

Amadeusz Sławiński <amade>
Group administrator
Fri 11 Oct 2019 01:55:36 PM UTC, comment #3: 

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.

Axel Beckert <abe>
Mon 26 Jan 2009 09:54:58 PM UTC, comment #2: 

Could the 'zombie' command be responsible for this? Could you try unsetting the zombie setting (using the 'zombie' command without any params), then terminating the process?

Sadrul Habib Chowdhury <sadrul>
Group administrator
Thu 15 Jan 2009 10:55:24 PM UTC, comment #1: 

No ideas, really, other than staring at the source for a while to see if anything jumps out (or, perhaps, to see if gdb allows it to be reproduced, unlike strace).

Micah Cowan <micahcowan>
Sun 14 Dec 2008 07:36:20 AM UTC, original submission:  

I came across a funny thing: each process started by screen in a new window (eg. /bin/bash) will become a zombie after exiting it (eg. typing exit).

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)

Any ideas where to look at, how to pinpoint the problem?

Michal Svoboda <pht1>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #52866:  screen-zombies-master.patch added by vinc17 (878B - text/x-patch - new patch for master)
file #51740:  screen-zombies.patch added by vinc17 (948B - text/x-patch - patch, which consists in sending SIGCHLD to oneself)
file #48133:  try3.patch added by amade (2KiB - text/x-patch - Just run handler directly instead using GotSigChld to schedule)
file #48132:  try2.patch added by amade (769B - text/x-patch - Decrease GotSigChld counter in better place)
file #47810:  0001-Fix-screen-leaving-zombie-processes.patch added by amade (1KiB - text/x-patch - New version of patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by anaumov (Posted a comment)
  • -email is unavailable- added by vinc17 (Posted a comment)
  • -email is unavailable- added by saper (Posted a comment)
  • -email is unavailable- added by amade (Posted a comment)
  • -email is unavailable- added by abe (Posted a comment)
  • -email is unavailable- added by sadrul (Posted a comment)
  • -email is unavailable- added by pht1 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 17 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-08-18 anaumov Open/ClosedOpen Closed
        Fixed ReleaseNone 4.9.1
    2022-02-17 anaumov StatusConfirmed Fixed
    2022-02-16 vinc17 Attached File- Added screen-zombies-master.patch, #52866
    2022-02-15 anaumov StatusWorks For Me Confirmed
        Planned ReleaseLater 4.9.1
    2022-02-02 anaumov CategoryNone Program Logic
        StatusNeed Investigation Works For Me
        Work Required1 - Days None
    2021-08-05 vinc17 Attached File- Added screen-zombies.patch, #51740
    2019-12-30 micahcowan Carbon-CopyRemoved 60294 -
    2019-12-28 amade Attached File- Added try3.patch, #48133
    2019-12-28 amade Attached File- Added try2.patch, #48132
    2019-11-06 amade Attached File- Added 0001-Fix-screen-leaving-zombie-processes.patch, #47810
    2009-01-15 micahcowan StatusNone Need Investigation
        Planned ReleaseNone Later
        Work RequiredNone 1 - Days

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code