Denmark
This space intentionally left blank.
Comment by ~kennylevinsen on ~kennylevinsen/greetd
sway is most likely dying from the GPU reset. Make sure you're running sway 1.8, or try master of sway and wlroots.
If you want to collect sway's output, start sway as
systemd-cat --identifier sway -- sway. This is best done by starting a wrapper script instead of starting sway directly - e.g., make /usr/local/bin/sway-run, make it executable and put this in it:#!/bin/sh # any environment variables you'd like exec systemd-cat --identifier=sway -- sway $@Then you will be able to read the output with
journalctl -t sway.
Comment by ~kennylevinsen on ~kennylevinsen/greetd
Once your session is active, greetd only waits for it to end and does not interact with anything. If you see gtkgreet again, while it could mean that greetd got restarted, it is more likely to mean that your display server crashed and greetd just did its job by letting you log back in.
journalctl should have some info about what happened and what, if anything, crashed.
Comment by ~kennylevinsen on ~kennylevinsen/wlsunset
REPORTED RESOLVED FIXED
Comment by ~kennylevinsen on ~kennylevinsen/wlsunset
wlsunset dies as intended when the wayland display is closed. If the timing is right, the error handling of this goes bad and you get the infinite loop.
If this was caused by shutting down sway rather than a protocol error, then the issue is fixed.
Comment by ~kennylevinsen on ~kennylevinsen/wlsunset
Seems like the Wayland display connection died, with wlsunset handling EPIPE poorly.
Without knowing why the connection died I cannot fix the former. The latter should be fixed in cc9251d5c39ff3e4beb130306722d7b90d1031ab.
Comment by ~kennylevinsen on ~kennylevinsen/greetd
(Note that I am open to adding whatever it expects as a feature request, just pointing the debugging effort in the right direction.)
Comment by ~kennylevinsen on ~kennylevinsen/greetd
greetd does not use threads, and all PAM processing is done in a single process, so there are no races. The crash is happening in pam_ecryptfs while PAM is asking it for it's opinion on allowing you to authenticate, much before the session is started.
It may be that greetd is triggering the pam_ecryptfs bug (e.g. by not providing an environment variable it thought would always be there), but a crash in pam_ecyptfs is a bug in pam_ecryptfs.
Comment by ~kennylevinsen on ~kennylevinsen/greetd
Rebuild the ecryptfs-utils package with debug symbols. Refer to your distro documentation for more details.
Note that a crash in pam_ecryptfs.so is not a greetd bug.
Comment by ~kennylevinsen on ~kennylevinsen/greetd
The segfault is triggered from with pam_ecryptfs.so, somewhere in this function: https://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/view/head:/src/pam_ecryptfs/pam_ecryptfs.c#L125.
Get debug symbols for pam_ecryptfs.so (ecryptfs-utils) to get a more useful stacktrace.
Comment by ~kennylevinsen on ~kennylevinsen/seatd
REPORTED RESOLVED CLOSED