[systemd-devel] Questions about systemd's "root storage daemon" concept

[Lennart Poettering]

On Sa, 23.01.21 02:44, Martin Wilck (mwilck at suse.com) wrote:

> Hi
>
> I'm experimenting with systemd's root storage daemon concept
> (https://systemd.io/ROOT_STORAGE_DAEMONS/).
>
> I'm starting my daemon from a service unit in the initrd, and
> I set argv[0][0] to '@', as suggested in the text.
>
> So far so good, the daemon isn't killed. 
>
> But a lot more is necessary to make this actually *work*. Here's a list
> of issues I found, and what ideas I've had so far how to deal with
> them. I'd appreciate some guidance.
>
> 1) Even if a daemon is exempted from being killed by killall(), the
> unit it belongs to will be stopped when initrd-switch-root.target is
> isolated, and that will normally cause the daemon to be stopped, too.
> AFAICS, the only way to ensure the daemon is not killed is by setting
> "KillMode=none" in the unit file. Right? Any other mode would send
> SIGKILL sooner or later even if my daemon was smart enough to ignore
> SIGTERM when running in the intird.

Consider using IgnoreOnIsolate=.

> 3) The daemon that has been started in the initrd's root file system
> is unable to access e.g. the /dev file system after switching
> root. I haven't yet systematically analyzed which file systems are
> available.   I suppose this must be handled by creating bind mounts,
> but I need guidance how to do this. Or would it be
> possible/advisable for the daemon to also re-execute itself under
> the real root, like systemd itself? I thought the root storage
> daemon idea was developed to prevent exactly that.

Not sure why it wouldn't be able to access /dev after switching. We do
not allocate any new instance of that, it's always the same devtmpfs
instance.

Do not reexec onto the host fs, that's really not how this should be
done.

> 4) Most daemons that might qualify as "root storage daemon" also have
> a "normal" mode, when the storage they serve is _not_ used as root FS,
> just for data storage. In that case, it's probably preferrable to run
> them from inside the root FS rather than as root storage daemon. That
> has various advantages, e.g. the possibility to update the sofware
> without rebooting. It's not clear to me yet how to handle the two
> options (root and non-root) cleanly with unit files.

option one: have two unit files? i.e. two instances of the subsystem,
one managing the root storage, and one the rest.

option two: if you cannot have multiple instances of your subsystem,
then the only option is to make the initrd version manage
everything. But of course, that sucks, but there's little one can do
about that.

Lennart

--
Lennart Poettering, Berlin