This is lovely, thank you.

One thing, which might very well be entirely my fault, but I pulled this onto my system with a standard dnf --enable-repo updates-testing upgrade niri, and the compositor unexpectedly restarted during the update process. This was very visible and dropped the only graphical application I was running at the time (foot, housing the dnf upgrade, luckily by way of tmux).

My logs read something like this:

Sep 11 23:27:05 flaglock6 systemd-logind[1488]: Session c3 logged out. Waiting for processes to exit.
Sep 11 23:27:05 flaglock6 systemd-logind[1488]: Removed session c3.
[snip]
Sep 11 23:27:06 flaglock6 systemd[1]: Reloading user@1000.service - User Manager for UID 1000...
Sep 11 23:27:06 flaglock6 systemd[3152]: Reexecuting.
Sep 11 23:27:06 flaglock6 systemd[2556]: Reexecuting.
[snip]
Sep 11 23:27:07 flaglock6 systemd[2556]: Queuing reload/restart jobs for marked units…
Sep 11 23:27:07 flaglock6 systemd[2556]: Stopping niri.service - A scrollable-tiling Wayland compositor...
Sep 11 23:27:07 flaglock6 gnome-control-c[2890]: Lost connection to Wayland compositor.
Sep 11 23:27:07 flaglock6 xdg-desktop-por[2857]: Lost connection to Wayland compositor.
Sep 11 23:27:07 flaglock6 xdg-desktop-por[2908]: Error reading events from display: Broken pipe
Sep 11 23:27:07 flaglock6 evolution-alarm[2766]: Error reading events from display: Broken pipe
Sep 11 23:27:07 flaglock6 systemd[2556]: app-niri-swaybg-2752.scope: Consumed 1.024s CPU time, 194.3M memory peak.
Sep 11 23:27:07 flaglock6 systemd[2556]: Stopped niri.service - A scrollable-tiling Wayland compositor.
Sep 11 23:27:07 flaglock6 systemd[2556]: niri.service: Consumed 1.400s CPU time, 86M memory peak.

I'm guessing this is some side effect of %systemd_user_post niri.service in the %post section, which blame says isn't some recent addition (but I think this might be my first time upgrading niri, since I only installed it a month or two ago). Of course I am not familiar with packaging (and certainly not the ins and outs of niri) --- just FYI.

Strange - I don't think this should happen. I'm intentionally using %systemd_user_postun_with_reload and not the _with_restart variant - this should only cause systemd to reload the updated service definition, not to actually restart the service 🤔 Still, updating a system "live" can have unintended consequences like this, which is why it's recommended to use offline upgrades :)

Oh heavens, I've been doing this wrong for over a decade then. Thanks for the pointer.

(For future readers: man dnf5-offline)