Package: sway Version: 1.8.1-1 Severity: minor This is a rather hairy problem.
I have made the perhaps-ill-advised configuration of hooking up my wayland / sway session as a systemd --user unit. When i run containers with podman and they exit with an error, the whole session crashes. The last lines before death are: jun 28 16:53:39 angela podman[298210]: 2023-06-28 16:53:39.53329688 -0400 EDT m=+1.000110624 container died de96bebba97ba50229c01a93e1a0928c34b954b50ca1ea295c20c1d3c2970137 (image=quay.io/minio/mc:latest [...] jun 28 16:53:39 angela podman[298287]: 2023-06-28 16:53:39.624658051 -0400 EDT m=+0.086326242 container cleanup [...] jun 28 16:53:39 angela systemd[296508]: sway.service: Main process exited, code=exited, status=1/FAILURE The podman lines have way more stuff in there, but i spare you the details... My .config/systemd/user/ setup is documented in https://anarc.at/software/desktop/wayland/#systemd-integration A plain: podman run docker.io/library/debian:bookworm-slim ... can reproduce the issue. Note that the command needs to be ran from a terminal spawned by Sway itself, say with $mod-Return. If I start it from a separate unit or with `systemd-run`, it doesn't crash the session on exit. If I run: podman run -it --rm docker.io/library/debian:bookworm-slim I notice that `conmon(8)` takes over the Main PID which is essentially the core of the problem here. Because Sway refuses to support systemd: https://github.com/swaywm/sway/issues/5160 ... it does not send a proper "READY" state through sd_notify as other services might normally do. In general, that's not *too* much of a problem: systemd can start and manage services fine without this. But in this case, I'm starting other units that *do* depend on Sway being ready to run, so I *do* need this state to properly chain dependencies here. So I have this horror in my sway config: exec dbus-update-activation-environment --systemd XDG_CURRENT_DESKTOP=sway \ && systemctl --user import-environment SWAYSOCK \ DISPLAY \ I3SOCK \ WAYLAND_DISPLAY \ XCURSOR_SIZE \ XCURSOR_THEME \ && systemd-notify --ready And the systemd sway.service has: NotifyAccess=all ... which is how conmon is able to hijack the Main PID. A workaround is to change the Sway keybindings to start processes with systemd, like this: # start a terminal # # we start it as a systemd unit on the fly otherwise podman takes over # the Main PID of the sway.service and container exits crash the whole # session bindsym $mod+Return exec systemd-run --user foot The real fix here would be for Sway to send something to sd-daemon. Of course, the easiest way to do this would be to do a clever call to sd_notify() just at the right place in the Sway source code, but there's little chance such a patch would be merged upstream... I looked at the code, and the actual sd_notify() call is not *that* complex. It opens a UNIX socket and shoves a message in there, probably just READY=1. Surely Sway could figure out how to write to a socket on its own? Hell, it could even just vendor this stupid piece of code here: https://sources.debian.org/src/systemd/253-4/src/libsystemd/sd-daemon/sd-daemon.c/#L453-L602 Anyway, I don't mean to troll here, but this was a really complicated bug to figure out and to fix for me (thanks #debian-systemd folks!), so I figured I would at *least* document it here somehow. The best case scenario for me is that sway gets sd_notify support. A working compromise could be an update to the README.Debian file or even better a sample sway config that has the right knobs. Failing that, I'm happy to just see this bug closed and add this to the pile of custom weird shit I carry around everywhere. Cheers! :) -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sway depends on: ii libc6 2.36-9 ii libcairo2 1.16.0-7 ii libevdev2 1.13.0+dfsg-1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgl1-mesa-dri 22.3.6-1+deb12u1 ii libgles2 1.6.0-1 ii libglib2.0-0 2.74.6-2 ii libinput10 1.22.1-1 ii libjson-c5 0.16-2 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-0 1.50.12+ds-1 ii libpcre2-8-0 10.42-1 ii libpixman-1-0 0.42.2-1 ii libsystemd0 252.6-1 ii libudev1 252.6-1 ii libwayland-client0 1.21.0-1 ii libwayland-cursor0 1.21.0-1 ii libwayland-server0 1.21.0-1 ii libwlroots11 0.16.2-1 ii libxcb-icccm4 0.4.1-1.1 ii libxcb1 1.15-1 ii libxkbcommon0 1.5.0-1 ii polkitd 122-3 ii swaybg 1.2.0-1 Versions of packages sway recommends: ii foot 1.13.1-2 ii suckless-tools 47-1 pn sway-backgrounds <none> Versions of packages sway suggests: ii swayidle 1.8.0-1 ii swaylock 1.7.2-1 ii xdg-desktop-portal-wlr 0.7.0-1 -- no debconf information
