Any update to core systemd components also requires a system reboot. Without the reboot, you'll risk crashes, because those core components assume all of them run the same version, and have basically no error checking. A typical symptom is your desktop environment crashing, because your (user) dbus-daemon process has crashed.
The only one that could be problematic to restart is init, PID 1, which can be restarted with systemctl daemon-reexec. What am I missing?
You're missing the fact that desktop update managers do ask/require reboots whenever a systemd-subsumed core service package is updated. If you do not reboot, and e.g. dbus-daemon binaries are updated, it is common for the desktop manager (gnome or cinnamon for example) to crash at some point.
If you're doing live patching using kpatch or ksplice or similar, I'm not sure why systemd comes into it, both work fine on systemd systems, and systemd shouldn't care about the kernel, it is completely userland. Care to elaborate?
Prior to systemd, when e.g. dbus-daemon was updated, it sufficed to restart just the updated daemon (or for nontechnical users, to log out and back in achieved the same) to ensure the updated binaries were being executed. It no longer works, because of the tight integration of the daemons to the root systemd.
(After updating core system packages, it used to suffice to restart the affected binaries; I did this in a staggered manner, to minimize the effect on provided services, but for users, told them to simply log out and back in, to ensure they were using the updated binaries and applications. This often still works on server machines without desktop environments, but isn't anymore what the developers recommend: they assume everyone reboots the machines after core system updates.)
As an example, after a few days of uptime, log out of your desktop session, then observe the process list. Very often, say 10-25% of the time, some of your user service processes (dbus-daemon etc.) are still running. This is a problem, and instead of fixing it, distro maintainers decided just to set the update managers to asking the user whether they wanted to reboot; and changed the documentation to recommend rebooting as the first "fix" to everything.
I guess you are referring to polkit as 'privilege separation' (of course the kernel is, as ever, managing privilege separation)? This isn't part of systemd
Yes, it is.
polkit manages privilege escalation to user services that need it. In practice, it means that an application can use polkit to elevate its privileges without user intervention.
I'm sure you want to quibble about "privilege escalation service is not 'privilege separation'", but I disagree.
Its freedesktop gitlab README describes itself as "polkit is a toolkit for defining and handling authorizations".
The problem with polkit is not exactly what it does –– the problem, fine-grained permission/privilege control, is real and
sudo is designed for human users, not to be used by services –– but its implementation and how the developers try to avoid being noticed by users. Consider polkits
Changelog (it's empty), or a typical comment by one of the polkit contributors (Simon McVittie):
"It should generally not be necessary for users to contact the original maintainer."dbus is used for IPC
and has been subsumed by systemd. There are still non-systemd dbus implementations (that e.g. Devuan uses).
The core issue with the standard dbus-daemon is that it no longer forks processes itself, it only tells systemd to fork and execute them. Don't you see that no matter what you say about project organization, that is by definition subsumption of functionality: the dbus-daemon no longer performs the action, only delegates it to systemd.
it is clear to me that the 'old way' needed to go.
Sure, that I do completely agree with. I personally only used the 'old way' for the initial bootup, not for runtime service management, on servers I maintained, since 2001 or so. On desktops, I wasn't happy with the service IPC (what is essentially now dbus) approaches, because of their complexity.
(I also loved to use LDAP for larger organizations, as its configuration and inter-server-operability suited my needs very well. Then, Active Directory came along, and skewed everything so that now everything is Windows-oriented, and Unix/POSIX support is a second-tier citizen. Annoying as hell for someone who only uses Linux and BSDs, and not Windows at all.)
However, the service management side was already a solved problem (as shown by runit, daemontools, and other service managers), as was init (as shown by e.g. upstart).
There is absolutely no sane reason to require system services to use dbus to report their status –– neither the protocol or its implementation is at all robust. Do you recall the kdbus debacle, when they (well, Greg KH, who is a reliable and responsible developer, but really didn't think before submitting it) tried to push it into the kernel? Even then, a lot of people pointed out much better ways to implement the same in user space. The dbus developers main objection was that it was too much work, and what they have now works fine for them.
It would have been much better to simply continue forward with the dependency-based inits, with a very simple sub-init service manager using Unix Domain sockets to maintain connections to each service. This would have required adding a library and library status calls for every daemon, but at that point it was seen as "too much work" or "infeasible". Yet, that's what eventually did happen with dbus anyway.
(Why Unix Domain? Because on Linux and BSDs, it provides a way to both authenticate the communicating processes (PID, UID, GID), as well as pass new descriptors. Why not? Because it is not supported in Windows. I wonder why that would matter to dbus developers? I do not know.)
As shown by daemontools and runit in practice, they were much more robust in managing long-running services.
nothing stopping alternative implementations
Except systemd developers in e.g. Debian. They very actively object to any kind of interoperability with non-systemd components.
Just go look at debian-ctte mailing list and the bugzilla; such discussions are extremely common.
What the hell incentive does the Debian team have to choose systemd for vendor lock-in or whatever it is being accused of here??
There is no "Debian team". It is a community with extremely well defined rules, including very strict voting.
One of the core principles there is that maintainers are assumed to know what they're doing. In case of disputes and problems, the Debian Technical Committee (CTTE) can be asked to provide an opinion.
When Debian switched from SysV init to systemd, the idea was that maintainers would work together to ensure "init freedom". In 2014, Ian Jackson called for a general resolution (basically a vote by all Debian maintainers), to preserve the choice of init systems for the users. This kinda-sorta failed, because most maintainers felt it would have forced maintainers to maintain stuff they weren't interested in.
The systemd component maintainers took that as a carte blanche for rejecting all interoperability between init systems, and started actively blocking contributions to allow users to switch from systemd to another init system. Such actions have been taken to Debian CTTE many, many times now, but they're unwilling to override a specific maintainer exactly because they do not want to force maintainers to maintain code only others need (compare to e.g. out-of-kernel drivers, for example).
I understand the viewpoint, but I disagree, because I consider respecting the user freedom and interoperability more important than maintainer freedom,
for core components of the system. I do systems level programming myself, and have contributed fixes and patches to everything from the Linux kernel to glibc and gcc, so I'm not saying here what others should do; I'm describing how I see
our responsibilities and freedoms as core system developers/contributors.
stuck to SysV init for longer than most.
Do not forget, that the question in Debian was NOT whether to stay with SysV or switch to systemd.
It was whether to switch from SysV to upstart or systemd. The competition was between upstart and systemd, not between SysV and systemd.