switch-to-configuration-ng: wait for NameOwnerChanged after systemd Reexecute

To re-execute a systemd manager interface, the
current switch-to-configuration-ng code calls the
org.freedesktop.systemd1.Manager.Reexecute method on D-Bus.

As noted in a comment, the systemd manager does not reply to that
method call (it has the org.freedesktop.DBus.Method.NoReply attribute).
Instead, to signal when it is done re-executing, it passes its old D-Bus
connection socket to the new systemd manager and once the new systemd
manager is ready to receive D-Bus messages on the new D-Bus connection
socket, it will close the old connection socket. As the old connection
socket is closed, the D-Bus daemon assigns the org.freedesktop.systemd1
bus name to the new D-Bus connection [1].

The dbus-codegen crate does not support the
org.freedesktop.DBus.Method.NoReply attribute. What currently
happens in switch-to-configuration-ng is that it blocks until the
old connection socket is closed which makes the D-Bus daemon send a
org.freedesktop.DBus.Error.NoReply error to switch-to-configuration-ng
which then unblocks it.

If the systemd manager takes a long time to re-execute (more than 10
seconds), then the method call can also timeout which means that
switch-to-configuration-ng will proceed with the next systemd manager
method calls, leading to the following error:

> Error: Failed to restart nixos-activation.service
>
> Caused by:
>     Message recipient disconnected from message bus without replying

This was observed on a server with a very large number of
filesystem mounts that make re-execution take more than 10
seconds.

Use the org.freedesktop.DBus.NameOwnerChanged signal [2] to determine
when systemd is done reexecuting and is ready to receive new D-Bus
messages again.

[1]: https://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-overview
[2]: https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-name-owner-changed

0 files changed, 0 insertions, 0 deletions