Here's the 3rd installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.
You might have heard of the sd_notify() protocol that services running on systemd can use to notify the service manager about status changes, in particular about service readiness. systemd uses that to synchronize start, reload and stop operations between daemon code and service manager (as well as a multitude of other things).
But did you know that the service manager itself also sends out sd_notify() messages to let whatever started it know about its own status changes?
How is that useful you wonder? When systemd runs in a container, a container manager can use this to determine when precisely the container is ready and connectible. When systemd is running in the per-user instance, then the per-system instance can know this way when it fully started up. Finally, since v253 the interface supports AF_VSOCK…
… for communication, and thus a VMM can also learn when the system is fully booted up, and thus connectible.
With v256 we extended this logic further. sd_notify() is an extensible protocol after all, you can send more than just READY=1, RELOADING=1, STOPPING=1.
So what is new in v256 precisely? We now send up finer grained messages. Specifically: X_SYSTEMD_UNIT_ACTIVE= is a message we send out whenever a target unit is fully activated. The assignment's value let's you know which.
You might wonder: what is that good for? The idea is that it's both a progess notification *and* a feature notification. We also added a new generic ssh-access.target after all, that SSH servers are supposed to order themselves before and pull in. Thus, when a VMM/container manager see X_SYSTEMD_UNIT_ACTIVE=ssh-access.target its indication that the system is – at that very instance – connectible via SSH. Or in other words, they can start up a system and immediately log in, …
… without waiting longer than necessary, and without failed attempts to connect.
There are also two new messages that report the hostname and the machine ID to the container manager/VMM the moment they have been settled and set. In particular the hostname is useful, to know under which name to connect to the system later. Then, there's a new message that notifies the moment that all UNIX process signal handlers are installed by PID 1, and thus from which point on it will react to SIGRTMIN+14…
… for shutting down the system (here too it's a synchronization point *and* a feature notification mechanism).
Finally there are new messages that report the precise selected method of shutdown at shutdown time (reboot, halt, poweroff, …) and the "reboot argument", as specified via systemctl --reboot-argument=.
Or in other words: we now have a very simple, very generic mechanism in place that allow VMMs/container managers to know both features of the payload, and synchronize on key state…
… changes of it.
And that's all for now. Let's see if and when I'll post the 4th installment of this series.