[systemd-devel] How to add a unit path to systemd?

[Lennart Poettering]

On Sa, 11.08.18 10:21, Andrei Borzenkov (arvidjaar at gmail.com) wrote:

> 10.08.2018 20:10, Daniel Wang пишет:
> >> Alternatively, you actually can issue daemon reload during the
> > boot process
> > 
> > Suppose I use a systemd service (say foo.service) to do this, is it a
> > supported/recommended practice to do a daemon reload as part of a unit's
> > activation (i.e., through its ExecStart)?
> 
> From practical experience - there is slow but constant stream of bug
> fixes related to daemon-reload. It is supposed to be transparent, but it
> *is* losing parts of systemd state.

Not anymore. At this point if the individual unit files don't change
across the reload it should be fully reliable to reload PID 1. 

What remains is the ambiguity if you change a unit file's set of
ExecStart=  lines and it is not clear where to proceed while systemd
is executing one of them that doesn't exist anymore in the new
version.

In older systemd versions we'd avoid any ambiguity by always
continuing with the frist ExecStart= line in a unit file after a
reload, which was deterministic in a way, but pretty often wrong. 

> So my personal opinion - daemon-reload is suitable for one-off task in
> mostly static controlled environment (like updating in-memory unit
> definition after editing on-disk file after initial boot was completed),
> but using it during high volume activity like system boot increases
> chances of misbehavior. Problems caused by daemon-reload are rather hard
> to diagnose and reproduce (as they are highly dynamic - you need to hit
> the right bug in the right moment).

I agree with this sentiment. It's better to keep "daemon-reload" out
of the clean code paths of booting, and using it exclusively for
exceptional code paths, i.e. during upgrades and reconfiguration.

> Nor do I think that daemon-reload was ever even designed for such
> use cases.

That is pretty much true. (but see the initrd case, mentioned in the
other mail)

Lennart

-- 
Lennart Poettering, Red Hat