lightdm coredump - too many open files

Bug #1387525 reported by Max
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Light Display Manager
New
Undecided
Unassigned

Bug Description

Got two coredumps on my work PC. Both of them occurs during the off-hours while PC is locked (dm-tool lock). XFCE session was dropped.

Archlinux x64
Lightdm 1.12.1

Information about the last coredump is added, coredump file is attached

Systemd log:

Oct 29 18:48:07 *** lightdm[477]: ** (lightdm:477): WARNING **: Failed to create pipes: Too many open files
Oct 29 18:48:07 *** lightdm[477]: ** (lightdm:477): WARNING **: Error opening /dev/console: Too many open files
Oct 29 18:48:07 *** lightdm[477]: ** (lightdm:477): WARNING **: Error opening /dev/console: Too many open files
Oct 29 18:48:07 *** lightdm[477]: (lightdm:477): GLib-ERROR **: Creating pipes for GWakeup: Too many open files
Oct 29 18:48:07 *** kernel: traps: lightdm[477] trap int3 ip:7fb1e189ba80 sp:7ffffb6009c0 error:0

Oct 29 18:48:07 *** lightdm[14355]: pam_unix(lightdm-greeter:session): session closed for user lightdm
Oct 29 18:48:07 *** systemd[1]: lightdm.service: main process exited, code=dumped, status=5/TRAP
Oct 29 18:48:07 *** systemd[1]: Unit lightdm.service entered failed state.

Oct 29 18:48:07 *** systemd[1]: lightdm.service holdoff time over, scheduling restart.
Oct 29 18:48:07 *** systemd[1]: Cannot add dependency job for unit cgrules.service, ignoring: Unit cgrules.service failed to load: No such file or directory.
Oct 29 18:48:07 *** systemd[1]: Cannot add dependency job for unit cgconfig.service, ignoring: Unit cgconfig.service failed to load: No such file or directory.
Oct 29 18:48:07 *** systemd[1]: Stopping Light Display Manager...
Oct 29 18:48:07 *** systemd[1]: Starting Light Display Manager...
Oct 29 18:48:07 *** systemd[1]: Started Light Display Manager.

Oct 29 18:48:08 *** lightdm[13965]: pam_unix(lightdm-greeter:session): session opened for user lightdm by (uid=0)
Oct 29 18:48:08 *** systemd[1]: Starting Session c21 of user lightdm.
Oct 29 18:48:08 *** systemd-logind[432]: New session c21 of user lightdm.
Oct 29 18:48:08 *** systemd[1]: Started Session c21 of user lightdm.
Oct 29 18:48:08 *** lightdm[675]: pam_unix(lightdm:session): session closed for user ***

Oct 29 18:48:10 *** systemd-logind[432]: Removed session c20.
Oct 29 18:48:10 *** systemd-logind[432]: Removed session c1.
Oct 29 18:48:11 *** systemd-coredump[13934]: Process 477 (lightdm) of user 0 dumped core.

Coredump:

↪ sudo coredumpctl gdb lightdm
           PID: 477 (lightdm)
           UID: 0 (root)
           GID: 0 (root)
        Signal: 5 (TRAP)
     Timestamp: Wed 2014-10-29 18:48:07 MSK (14h ago)
  Command Line: /usr/bin/lightdm
    Executable: /usr/bin/lightdm
 Control Group: /system.slice/lightdm.service
          Unit: lightdm.service
         Slice: system.slice
       Boot ID: 940c458a7e8d4931992b969962bb2390
    Machine ID: e393b6a241644f0c92272c96225bcbb9
      Hostname: ***
      Coredump: /var/lib/systemd/coredump/core.lightdm.0.940c458a7e8d4931992b969962bb2390.477.1414597687000000.xz
       Message: Process 477 (lightdm) of user 0 dumped core.

GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/lightdm...(no debugging symbols found)...done.
[New LWP 477]
[New LWP 483]
[New LWP 480]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/bin/lightdm'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0 0x00007fb1e189ba80 in g_logv () from /usr/lib/libglib-2.0.so.0
warning: File "/home/***/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
 add-auto-load-safe-path /home/***/.gdbinit
line to your configuration file "/root/.gdbinit".
To completely disable this security protection add
 set auto-load safe-path /
line to your configuration file "/root/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
 info "(gdb)Auto-loading safe path"
(gdb) bt
#0 0x00007fb1e189ba80 in g_logv () from /usr/lib/libglib-2.0.so.0
#1 0x00007fb1e189bcbf in g_log () from /usr/lib/libglib-2.0.so.0
#2 0x00007fb1e18d7ac2 in ?? () from /usr/lib/libglib-2.0.so.0
#3 0x00007fb1e18923d6 in g_main_context_new () from /usr/lib/libglib-2.0.so.0
#4 0x00007fb1e1e77232 in g_dbus_connection_send_message_with_reply_sync ()
   from /usr/lib/libgio-2.0.so.0
#5 0x00007fb1e1e776d2 in ?? () from /usr/lib/libgio-2.0.so.0
#6 0x00007fb1e1e79383 in g_dbus_connection_call_sync () from /usr/lib/libgio-2.0.so.0
#7 0x000000000040fa10 in ?? ()
#8 0x0000000000412988 in ?? ()
#9 0x0000000000413777 in ?? ()
#10 0x0000000000414e7f in ?? ()
#11 0x00007fb1e1b69484 in ?? () from /usr/lib/libgobject-2.0.so.0
#12 0x00007fb1e1b83077 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#13 0x00007fb1e1b839cf in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#14 0x00007fb1e1b69255 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#15 0x00007fb1e1b7af5c in ?? () from /usr/lib/libgobject-2.0.so.0
#16 0x00007fb1e1b83768 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#17 0x00007fb1e1b839cf in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#18 0x00007fb1e1891464 in ?? () from /usr/lib/libglib-2.0.so.0
#19 0x00007fb1e189492d in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#20 0x00007fb1e1894d08 in ?? () from /usr/lib/libglib-2.0.so.0
#21 0x00007fb1e1895032 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#22 0x0000000000407d01 in ?? ()
#23 0x00007fb1e0995040 in __libc_start_main () from /usr/lib/libc.so.6
#24 0x0000000000408749 in ?? ()
(gdb) q

Revision history for this message
Max (khaberev) wrote :
Revision history for this message
Max (khaberev) wrote :

Log file attached

Revision history for this message
Max (khaberev) wrote :

It seems that the rootcause is equal to the https://bugs.launchpad.net/lightdm/+bug/1190344.

I've monitored the FD usage of FIFO pipes and found that the number of FDs increases constantly. I tried to apply the patch from the https://bugs.launchpad.net/lightdm/+bug/1190344 and it solved the problem.

In my setup I have the "xautolock" tool which is configured to call "dm-tool lock" in the case on 10 minutes of inactivity. According to the lightdm logs, the "xautolock" tool calls the "dm-tool lock" regardless of the current state (unlocked or locked already). Lightdm creates new "session" for each call and deletes it immediately if the X session is locked already. During the "session" removal several FDs are lost.

I'm going to mark the bug as duplicate. However it is reasonable to revise the "locking" functionality and implement some optimizations if possible.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.