Arch Linux

So, this happens when registering a signal handler: g_unix_signal_add.

Usually this points into the direction of ABI mismatches..

[+0.83s] DEBUG: Session pid=3468: Running command /usr/bin/lightdm-gtk-greeter
[+0.83s] DEBUG: Creating shared data directory /var/lib/lightdm-data/lightdm
[+0.83s] DEBUG: Session pid=3468: Logging to /var/log/lightdm/seat0-greeter.log
[+1.45s] DEBUG: Seat seat0: Stopping; failed to start a greeter

the logfile is empty.

So, the question is, why doesn't the greeter start and segfault.

rebuilt both lightdm-gtk-greeter and glib2 with debugging information (options=debug in PKGBUILD).

Now the stacktrace looks like:

#0  0xb7178b25 in _g_log_abort (breakpoint=1) at ../glib/glib/gmessages.c:554
554         G_BREAKPOINT ();
(gdb) bt
#0  0xb7178b25 in _g_log_abort (breakpoint=1) at ../glib/glib/gmessages.c:554
#1  0xb716d230 in g_log_default_handler
    (log_domain=0xb71b40d0 "GLib", log_level=6, message=0x78ee60 "creating thread 'gmain': Error creating thread: Resource temporarily unavailable", unused_data=0x0) at ../glib/glib/gmessages.c:3111
#2  0xb7178d7d in g_logv
    (log_domain=0xb71b40d0 "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xb7207a67 "creating thread '%s': %s", args=0xbf85e91c "\262\320 \267") at ../glib/glib/gmessages.c:1350
#3  0xb7178f55 in g_log
    (log_domain=0xb71b40d0 "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xb7207a67 "creating thread '%s': %s") at ../glib/glib/gmessages.c:1413
#4  0xb715f67a in g_thread_new (name=0xb720d0b2 "gmain", func=0xb7180b70 , data=0x0)
    at ../glib/glib/gthread.c:830
#5  0xb717fa1e in g_get_worker_context () at ../glib/glib/gmain.c:5888
#6  0xb717fa7a in ref_unix_signal_handler_unlocked (signum=15, signum=)
    at ../glib/glib/gmain.c:5224
#7  0xb71348d7 in _g_main_create_unix_signal_watch (signum=15) at ../glib/glib/gmain.c:5332
#8  0xb71348d7 in g_unix_signal_source_new (signum=15, signum=)
    at ../glib/glib/glib-unix.c:222
#9  0xb71373ef in g_unix_signal_add_full
    (priority=0, signum=15, handler=0x495f90 , user_data=0x1, notify=0x0)
    at ../glib/glib/glib-unix.c:252
#10 0xb7137463 in g_unix_signal_add (signum=15, handler=0x495f90 , user_data=0x1)
--Type  for more, q to quit, c to continue without paging--
    at ../glib/glib/glib-unix.c:283
#11 0x00490145 in main (argc=, argv=) at lightdm-gtk-greeter.c:2768

creating thread 'gmain': Error creating thread: Resource temporarily unavailable

This is the interesting one. Why should creating a thread run out of resources? And which
resources?

This is not by any chance an unhandled EAGAIN?

[pid  6607] execve("/usr/bin/core_perl/plymouth", ["plymouth", "--ping"], 0xbfa9086c /* 22 vars */) = -1 ENOENT (No such file or directory)

this seems a collateral damage (aka hard-coded call to the bootup manager plymouth), not every
Linux distribution has a plymouth, so I hope, this is actually optional..
The -ping indicates, that plymouth is started with ping, to see whether it is around.
It doesn't seem to have something to do with our problem though..

There is a strace entry showing the greeter gets started:

[pid  6616] execve("/usr/bin/lightdm-gtk-greeter", ["/usr/bin/lightdm-gtk-greeter"], 0xf61510 /* 15 vars */) = 0

later the sighandler tries to open a new thread:

825       GThread *thread;
826
827       thread = g_thread_new_internal (name, g_thread_proxy, func, data, 0, &error);
828
829       if G_UNLIKELY (thread == NULL)
830         g_error ("creating thread '%s': %s", name ? name : "", error->message);
831
832       return thread;

So, if it runs out of resources here (due to a systemd limit, rlimit thing), this would
explain the startup issues..

There is also a suspicious:

[pid  6616] mmap2(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = -1 EAGAIN (Resource temporarily unavailable)

So, I check the rlimit settings used by systemd for login session..

Sounds related:

https://github.com/abrt/faf/issues/212

mmh. why does lightdm-gtk-greeter work on 64-bit Archlinux?

aha. the mmap works there.

lightdm-gtk-greeter.c

mlockall (MCL_CURRENT | MCL_FUTURE);

commenting that out lets the mmap2 succeed.

As we deal with passwords, just disabling the locking is maybe not the best idea.

Incrementing the systemd limit in lightdm.conf LimitMEMLOCK=2684354560
didn't help at all.

Locking the whole greeter with all GTK inside is maybe also not the wisest idea..

LimitMEMLOCK=infinity in /lib/systemd/system/lightdm.service seemed so help.