v255 added a new systemd-executor binary – instead of direct fork/setup/exec, now it's fork/exec(executor)/setup/exec(service), to avoid doing too much stuff after fork. But the binary is executed off an open fd, so even though you've upgraded it on disk, the manager is still holding onto its old copy.
I guess the latter ended up achieving the opposite of what it intended.
I think asking systemd to reexec itself after the upgrade is how you're supposed to handle it – i.e. first "systemctl daemon-reexec" the system manager (or "telinit u" if you like), then "systemctl --user daemon-reexec", or a mass "systemctl kill -s SIGRTMIN-25 user@\*.service". (On Arch it's one of the very few daemon restarts that are automatically done via post-upgrade hooks.)
On Sat, Jun 29, 2024, 22:05 Mike Gilbert <floppym@xxxxxxxxxx> wrote:
I recently added systemd v256 to Gentoo's ebuild repo. While testing
the upgrade process from v255, I have run into an issue.
After the upgrade, my KDE Plasma session stopped working, and I was
unable to execute a reboot from the GUI.
Looking at the journal, I see several messages like this one:
Jun 29 14:21:30 naomi systemd[2387904]:
/usr/lib/systemd/systemd-executor (deleted): error while loading
shared libraries: libsystemd-core-255.so: cannot open shared object
file: No such file or directory
It appears to be executing a deleted binary
(/usr/lib/systemd/systemd-executor), likely via /proc/1/fd/..., and
then fails when loading a deleted shared library
(libsystemd-core-255.so).
The new versions of these files do exist on the filesystem. Also, I
was able to reboot the system by switching to a text console and
pressing ctrl-alt-delete.
Any idea what happened here? I'm not sure if this is a systemd bug, or
if I missed something in my packaging script (ebuild).
