lightdm zombie process created while press escape button on Login screen

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/990661/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

Status changed to 'Confirmed' because the bug affects multiple users.

see also debian bug # 675351
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675351

Hamish

Robert, can I pass this off to you? I did some investigation (below), but I'm at a point where I don't understand the lightdm code nearly as well as you.

So there are two ways I can see to create zombies:
1) Press Escape in the greeter, which behind the scenes asks LightDM to start another authentication session for the user
2) Try to log in as a user that already has a session running

The same thread for these two ways to trigger zombie processes are authentication workflows that didn't come to fruition.

Looking in the log, the zombie matches the bits that say (for example, if zombie is pid 3704 after I tried to log in as an already-logged in user):

[+301.12s] DEBUG: Greeter start authentication for mike
[+301.12s] DEBUG: Started session 3704 with service 'lightdm', username 'mike'
[+301.15s] DEBUG: Session 3704 got 1 message(s) from PAM
[+301.15s] DEBUG: Prompt greeter with 1 message(s)
[+304.25s] DEBUG: Continue authentication
[+304.39s] DEBUG: Session 3704 authentication complete with return value 0: Success

However, looking at session lifecycles in lightdm has always made my eyes bleed. Robert, does the above make you think of anything? I'm guessing some class isn't cleaning up correctly on "early exits" from an authentication session.

(I should make it clear that when i say "try to log in as a user that already has a session running" I mean "SUCCESSFULLY log in". The thing that lightdm is apparently suprised about in this scenario is that we are switching VMs instead of starting a new user session.)

My repro case in the Duped bug (https://bugs.launchpad.net/lightdm/+bug/1003115) provides one more way to make zombies, just enter bad credentials.

The fix from trunk seems to have an issue (it keeps running processes for successful logins), 12.04.1 freeze was yesterday as well, let's not hurry that change and get it in after .1

Seb, what process are you seeing? LightDM does keep a root process open for each session (required to keep the PAM state for ending the session). This should be the same as before the patch.

Fixed in 1.3.3

This bug was fixed in the package lightdm - 1.3.3-0ubuntu1

---------------
lightdm (1.3.3-0ubuntu1) quantal; urgency=low

  [ Robert Ancell ]
  * New upstream release:
    - Add a new remote session type. These sessions create a temporary local
      account and authenticate against a remote server. The session is an
      application that accesses that remote session (e.g. VNC, RDP etc)
    - Support multiple simultaneous PAM prompts (LP: #1043593)
    - Set utmp ut_host field to the X display address (LP: #1027760)
    - Correctly reap unused authentication sessions (LP: #990661)
  * debian/liblightdm-gobject-1-0.symbols:
    - Updated

  [ Michael Terry ]
  * debian/patches/06_disable_remote_login.patch:
    - Always return an error when trying to log in to remote sessions,
      until the FFe is granted (which is bug 1040221)
 -- Robert Ancell <email address hidden> Thu, 30 Aug 2012 10:15:16 +1200

I see that the fix was released almost three weeks ago, but have not yet seen any update in my 12.04.1 LTS installation. Meanwhile the zombie attack continues. Will there be a backport to the LTS system soon?

Jim, the fix went into 12.10, not 12.04 yet. We didn't squeeze it in before because the archive was already frozen for 12.04.1. But now that it's out, there's nothing stopping us. Robert, can you look at that?

> We didn't squeeze it in before because the archive was already frozen for 12.04.1.
> But now that it's out, there's nothing stopping us.

monthly ping

thanks

In my ubuntu 12.04.1, the same bug displayed.

ps -A -ostat,ppid,pid,cmd | grep -e '^[Zz]'
Z 2526 2557 [lightdm-session] <defunct>

Where will be udate for this bug for precise system (12.04):
currently on my laptop I have 59 lightdm zombies...

Ubuntu 12.04 64 bits

Same problem but in my case I don't press ESC nor type a wrong password. Simply I open a new gnome session to another user. When I close (correctly) that session one new lightdm defunct process is created.

Ubuntu 12.04 is a LTS edition. This should be corrected!

By other side, I think this problem provokes another issue: "X11: Maximum number of clients reached"

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
Xorg 13855 root 1u unix 0xffff8802c79b5480 0t0 347859 socket
Xorg 13855 root 3u unix 0xffff8802c79b2700 0t0 347860 /tmp/.X11-unix/X0
Xorg 13855 root 30u unix 0xffff8802f62afb80 0t0 347868 socket
Xorg 13855 root 31u unix 0xffff88031cc91d40 0t0 346583 socket
Xorg 13855 root 32u unix 0xffff88031cc4b400 0t0 348243 socket
Xorg 13855 root 33u unix 0xffff8802c79b7840 0t0 343941 socket
Xorg 13855 root 34u unix 0xffff8802d08bd480 0t0 106650780 socket
Xorg 13855 root 35u unix 0xffff8802c79b6800 0t0 346616 socket
Xorg 13855 root 36u unix 0xffff8802c79b30c0 0t0 346621 socket
Xorg 13855 root 37u unix 0xffff8802d08bde40 0t0 106619756 socket
Xorg 13855 root 38u unix 0xffff88031a1c8340 0t0 349281 socket
Xorg 13855 root 39u unix 0xffff8802f62abdc0 0t0 349299 socket
Xorg 13855 root 40u unix 0xffff88031cc9eb40 0t0 349302 socket
Xorg 13855 root 41u unix 0xffff88002398a3c0 0t0 106653418 socket
Xorg 13855 root 42u unix 0xffff88031d30bdc0 0t0 314168 socket
Xorg 13855 root 43u unix 0xffff88031cc49a00 0t0 314173 socket
Xorg 13855 root 44u unix 0xffff88031a1cdb00 0t0 351343 socket
Xorg 13855 root 45u unix 0xffff8802c741eb40 0t0 348459 socket
Xorg 13855 root 46u unix 0xffff88031a1c9380 0t0 346891 socket
Xorg 13855 root 47u unix 0xffff8802d08b8d00 0t0 106655167 socket
Xorg 13855 root 48u unix 0xffff88002398fb80 0t0 106651520 socket
Xorg 13855 root 49u unix 0xffff8803098ff500 0t0 352401 socket
Xorg 13855 root 50u unix 0xffff8801183c2080 0t0 106652691 socket
Xorg 13855 root 51u unix 0xffff8802f3322a40 0t0 106653022 socket
Xorg 13855 root 52u unix 0xffff8802c79b7500 0t0 353514 socket
Xorg 13855 root 54u unix 0xffff88031cc98000 0t0 349930 socket
Xorg 13855 root 63u unix 0xffff88031d309380 0t0 488751 socket
Xorg 13855 root 64u unix 0xffff88002398ad80 0t0 489641 socket

UID PID PPID C STIME TTY STAT TIME CMD
root 13855 1815 1 Jan07 tty7 Ss+ 1...

Any progress on patching this on Precise?

Robert was pinged about this back on 9/12 since it wasn't ready before 12.04.1 but could be patched now. I've seen no update/response since...

the fix creates somewhat the opposite issue and lead to processes that keep running for session closed, see bug #1100469 ... that needs to be addressed before SRUing a fix

I still have this issue in Ubuntu 12.04.4 LTS

Encounter the same problem, too. (Ubuntu 13.04, upgraded from 12.04 LTS)