Back

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.

@idiot sd_notify() is a protocol any daemon should use to notify the service manager about state changes.The unprefixed messages are thus entirely generic, supposed to be implemented by any daemon. OTOH the messages prefixed with X_SYSTEMD_ are sent by one daemon only: systemd itself. They make little sense to be sent out by anyone but systemd itself.

@arianvp socket activation means that you can connect to a service before the service is up. It does not mean however that you can connect to it before the socket is bound. ssh-access.target is supposed to report exactly that, i.e. you are supposed to order it after sshd.socket (and not after sshd.service) if you follow what I am saying.

A vmm/container manager hence can wait for the target, and then connect, and everything will be nicely reliable, prompt and retry-free

@pid_eins Following that train of thought, is waiting for X_SYSTEMD_UNIT_ACTIVE=sockets.target as the VMM good enough in the general case?

@arianvp well, sockets.target only works for socket activated services, which unfortunately not everything qualifies as.

@hsaliak unlike af_unix and af_vsock, af_inet is unreliable, needs encryption/authentication and so on, comes available only during late boot, typically after dhcp and so on, and hence is a very very different beast.

@pid_eins I expected that to be the reason. Thanks for clarifying