🐛 After 16.19.2 update way-displays crashes and hits restart limit

[mwaltersva]

branch

stable

Architecture

x86_64

Description

After 16.19.2 desktop-settings update, way-displays crashes and hits restart limit. The desktop stays gray for several seconds after logging in. I think maybe the desktop is not ready when way-displays tries to start. Manually starting way-displays after everything is ready works fine. (systemctl --user start way-displays)

Reproduction steps

Login using sway-user-service session.

Screenshots

No response

Logs

Mar 19 06:27:23 ppi00216 way-displays[3861]: E [06:27:23]
Mar 19 06:27:23 ppi00216 way-displays[3861]: E [06:27:23] ERROR: Changes failed
Mar 19 06:27:23 ppi00216 way-displays[3861]: E [06:27:23]
Mar 19 06:27:23 ppi00216 way-displays[3861]: E [06:27:23] ERROR: Please raise an issue: https://github.com/alex-courtis/way-displays/issues
Mar 19 06:27:23 ppi00216 way-displays[3861]: E [06:27:23] ERROR: Attach this log and describe the events that occurred before this failure.
Mar 19 06:27:23 ppi00216 systemd[3140]: way-displays.service: Main process exited, code=exited, status=1/FAILURE
Mar 19 06:27:23 ppi00216 systemd[3140]: way-displays.service: Failed with result 'exit-code'.
Mar 19 06:27:23 ppi00216 systemd[3140]: way-displays.service: Scheduled restart job, restart counter is at 5.
Mar 19 06:27:23 ppi00216 systemd[3140]: way-displays.service: Start request repeated too quickly.
Mar 19 06:27:23 ppi00216 systemd[3140]: way-displays.service: Failed with result 'exit-code'.
Mar 19 06:27:23 ppi00216 systemd[3140]: Failed to start Auto Manages Your Wayland Displays.
Mar 19 06:27:33 ppi00216 systemd[3140]: Started Auto Manages Your Wayland Displays.

[boredland]

The last line of you logs says it started. Are you certain it doesn't eventually start? I am aware it struggles in the beginning tho - will have to find time to optimize it.

Please run ps -ef | grep way-displays after loging.

[mwaltersva]

matt 4632 4509 0 12:51 pts/1 00:00:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --exclude-dir=.idea --exclude-dir=.tox way-displays

I've attached the output of journalctl --user -xeu way-displays from a fresh boot.
way-display.log

It looks like it me be related to this issue from way-displays, but I haven't experienced it until the most recent release of manjaro-sway-settings. (I did make sure to run skel and reboot/etc).

Thank you for taking a look at this and your work on manjaro-sway.

[boredland]

looks like it may be related

So did one on the workarounds from that issue work? If so: which one?

[mwaltersva]

I wasn't able to find anything in that issue which fixed it. Adding myself to the input group fixed the "input warnings" from the log. I manually disabled VRF but I still experience the repeated way-displays crashing. One odd behavior that I only just now noticed is that: if I have my usb-c dock plugged in, with two external displays attached to it, way-displays works/starts correctly. If I'm not connected to the dock/displays then it crashes and hits the restart limit.

I'm happy to take this over to the way-displays repo if you think this isn't a manjaro-sway issue. The timing of it popping up just seemed suspect. Thank you.

[boredland]

Well, didn't you say manually starting way-displays afterwards works? Then I'd suspect something related to the startup behavior of the service unit I wrote. Sadly it works just fine here. But I wanted to take a closer look at those units (and perhaps create some more) soon.

Perhaps before I fix that, just exec_always way-displays in user space.

[gregorbg]

Just noting that I'm experiencing similar issues, most notably the gray screen after boot for ~3 seconds

[boredland]

Just noting that I'm experiencing similar issues, most notably the gray screen after boot for ~3 seconds

While even on my old thinkpad x1 gen6 this is far from 3 seconds, this "grey screen" thing I can reproduce too.

[mwaltersva]

I also get the grey screen behavior. i7-1360P (Framework 13). Here's a quick video if that helps: https://www.youtube.com/shorts/JF9iH6Q4dOM

[gregorbg]

While even on my old thinkpad x1 gen6 this is far from 3 seconds, this "grey screen" thing I can reproduce too.

Both my workstation and my laptop suffer from this, and both have relatively modern AMD processors (~3 years old).

I found out via accident the other day that I can "break through" the grey screen by manually opening dmenu (Super+D) while they grey screen is still there. It opens dmenu and shows my desktop as expected.

[boredland]

I currently lack time to debug this, but likely it is related to how dependencies ares structured in those modules, if somebody wants to debug this:

https://github.com/manjaro-sway/desktop-settings/tree/sway/community/sway/etc/systemd/user

[l-j-g]

i dont have this issue after debugging for #786. not sure exactly what would have fixed as i messed with a lot of things...

i would start with checking systemctl list-units --user for any units that fail. then checking their status, fixing or removing them if not needed... if it had to guess it would be something related to the looping restart of failed units in sway-user-service

for unit in $(systemctl --user --no-legend --state=failed --plain list-units | cut -f1 -d' '); do
	partof="$(systemctl --user show -p PartOf --value "$unit")"
	for target in sway-session.target wayland-session.target graphical-session.target; do
		if [ "$partof" = "$target" ]; then
			systemctl --user reset-failed "$unit"
			break
		fi
	done
done

[boredland]

I can't reproduce this, sorry. Perhaps it got solved when weeding out the system units..