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! :)