greetd segfaults [tuigreet keeps showing 'Please Wait...']


I installed greetd and tuigreet on Calculate/Gentoo and sometimes it works (starts sway) and sometimes it doesn't. tuigreet keeps showing 'Please Wait....' and in dmesg I can see: greetd[11550]: segfault at 7ffcba2bacb8 ip 00007fc93d9f9a07 sp 00007ffcba2bacb0 error 6 in libc-2.32.so[7fc93d9b5000+149000] Leaving tuigreet out of the equation and just using the default agetty shows a similar result.

Entering a wrong password also has the same effect.

I tried both versions in the Calculate/Gentoo repository (0.6.1 and 0.7.0) although with 0.6.1 it's slightly different, when entering a wrong pw there it return to a blank console screen with just a blinking cursor in the left corner. No message about the pw being wrong.


Angelo Machils

Assigned to
8 months ago
8 months ago
No labels applied.

~kennylevinsen 8 months ago

Please share the following generated from a debug build of greetd (i.e. no --release flag to cargo build, or the --debug flag to cargo install):

  1. Stderr when running greetd with RUST_BACKTRACE=full set
  2. Stacktrace from the coredump

~angelus1969 8 months ago


Is this what you're looking for?

thread 'main' panicked at 'unable to lock pages: Sys(ENOMEM)', greetd/src/main.rs:44:36 stack backtrace: 0: 0x55eef24955c0 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hfb5316c1 e3e8df58 1: 0x55eef24b3a8c - core::fmt::write::hdab8fed0b7ac9734 2: 0x55eef24933d7 - std::io::Write::write_fmt::heaefdca8f02933f8 3: 0x55eef24976d0 - std::panicking::default_hook::{{closure}}::h917202afcdf7c1aa 4: 0x55eef249741c - std::panicking::default_hook::h3506873702c2c65b 5: 0x55eef2497d33 - std::panicking::rust_panic_with_hook::hce5a45229bd02ffb 6: 0x55eef2497909 - std::panicking::begin_panic_handler::{{closure}}::hc323386853bc3a06 7: 0x55eef2495a4c - std::sys_common::backtrace::__rust_end_short_backtrace::hf6fe4bfae53c64c4 8: 0x55eef24978c9 - rust_begin_unwind 9: 0x55eef24b2341 - core::panicking::panic_fmt::h1306a1d4b917e589 10: 0x55eef24b2163 - core::result::unwrap_failed::h5026d7ce0acb876c 11: 0x55eef2359c4e - core::result::Result<T,E>::expect::hf24fce742e2bf608 at /rustc/1.47.0/library/core/src/result.rs:933 12: 0x55eef2333413 - greetd::main::{{closure}}::h4a63d0105974051a at /home/angelo/greetd-0.7.0/greetd/src/main.rs:44 Aborted

~kennylevinsen 8 months ago

You're running greetd as non-root, which doesn't work.

Either run it as root or temporarily add the environment variable to your existing init scripts.

~angelus1969 8 months ago

Okay, and where to find the result afterwards?

~kennylevinsen 8 months ago

Redirect stderr whereever you'd like with "2>/tmp/greetd.log" if you are not already capturing stderr somewhere.

~angelus1969 8 months ago

There is only one entry: warning: PAM 'greetd' service missing, falling back to 'login' (and this is when greetd failed)

~kennylevinsen 8 months ago

In that case it sounds like it crashed in C code. You should have a coredump somewhere depending on system configuration (/proc/sys/kernel/core_pattern).

With coredumpctl, do as root:

# coredumpctl debug greetd
(gdb) bt full

If you have a bare core file, do as root:

(gdb) bt full

In both cases, share the full output, including the initial output when gdb opened the core.

~angelus1969 8 months ago

I have one file core_pattern in /proc/sys/kernel but the command gdb ..... and then bt full only gives me: 'no stack'.

~kennylevinsen 8 months ago

/proc/sys/kernel/core_pattern is the file configuring what the kernel will do with core files. It is not a coredump itself.

You might want to go to #kennylevinsen on freenode.

~angelus1969 8 months ago*

There were several processes running with regards to greetd/tuigreet:

22008 greetd

22049 /usr/bin/greetd --session-worker 15

22072 /usr/bin/greetd --session-worker 14

22073 tuigreet --cmd sway

I've made a coredump of process 22008, I hope that's the correct one. See: https://pastebin.com/nDWbb4Hb



Register here or Log in to comment, or comment via email.