systemd
So, systemd's NOTIFY_SOCKET readiness notification mechanism has a sort of authentication mechanism by pid: it doesn't like it when the notification is sent from another process than the main one, unless you add the NotifyAccess=all directive. Okay, fair.
Except that even with this directive, it still can fail for some reason:
if an auxiliary process of the unit sends an sd_notify() message and immediately exits, the service manager might not be able to properly attribute the message to the unit, and thus will ignore it, even if NotifyAccess=all is set for it.
Huh? Even if the supervisor wants to check that the MAINPID= given in the message is the relevant unit, it shouldn't need the notifier process to still be around, but, let's ignore that for now. So, it has a barrier mechanism to tell the notifier to stick around until the supervisor has acknowledged it. What is that barrier mechanism? The notifier passes an fd to the supervisor via SCM_RIGHTS in the notification message, and when the supervisor closes that fd, it means it has acked the notification, and the notifier can now exit.
That's right, folks: it's a notification that the notification has been received!
There are two mistakes here: 1. the supervisor doesn't need the notifier process to be alive when processing the notification, and 2. NOTIFY_SOCKET being a socket means that any process can connect to it so the supervisor needs to authenticate the relevant unit.
And that is how a bad design decision cascades into a maze of complexity and inefficiency, and a pain to implement. Unless you're willing to use libsystemd to get access to sd_pid_notify_barrier(), good luck getting this to work right.
(systemd people will say this is conspiratorial, but if they wanted to force users to link against libsystemd, they wouldn't behave differently. But I really don't care if it's intentional or not. If it's not intentional, it's just terrible engineering.)
What would be a simpler way to handle all this? Have the supervisor run the unit with a pipe from the daemon to the supervisor, not a socket anyone can connect to. Processes that can write to the pipe are the ones that can inherit it, which means they're necessarily part of the same unit. No need for authentication via pid. When the supervisor receives a certain token on the pipe (e.g. a newline), it means that the daemon is ready. In the daemon or any process notifying on its behalf, that spells: write(fd, "\n", 1); and that's it.
In other words: the s6 readiness notification protocol, which is exactly what is described in the above paragraph, is as efficient as systemd's synchronization protocol for its notification protocol.
The real tragedy is that when you go through systemd with a looking glass, every part of it is this way. It still works, and nobody notices the inefficiencies because modern machines are blazingly fast, but it is. so. bad.
(Edit: typos)
Folks, I think we're now past the time where we can claim to be in the middle about generative AI usage.
You're either for it and okay with intellectual theft, racism, land grabs, polluted water, higher power bills, and creating an addicted population that can't think.
Or you're against it.
Building a laser cutter (for PCB manufacture) with a NdCGY laser; while being all open hardware.
Building only arch:any/all Debian packages:
- dpkg-buildpackage: -B/-A
- pbuilder: --binary-arch/--binary-indep
- sbuild: --no-arch-all/--no-arch-any
- apt build-dep: --arch-only/--indep-only
Of course I can't remember all 4 of those pairs so I have to have to look at the man page nearly every time.
07.04.1926: Die Irin Violet Gibson versucht Mussolini zu töten, doch beim zweiten Schuss klemmt die Waffe: https://www.spiegel.de/geschichte/violet-gibson-die-irin-die-1926-auf-benito-mussolini-schoss-a-aed02cf5-f364-4d3a-82f6-10be11100075
Q: What is common between PCB electromagnetic compatibility and Feng Shui?
A: Both have gurus that tell you that you're disrupting the flow of energy, and ask you to fix the layout by moving things around.
