Is it safe to issue "systemctl daemon-reload" during boot?

[arvidjaar@xxxxxxxxx (Andrei Borzenkov)]

04.05.2018 17:32, Thorsten Schöning пиÑ?еÑ?:
> Hi all,
> 
> I'm using Ubuntu 16.04 LTS server with BTRFS, which created one
> subvolume for / and another one for /home. For various reasons I'm
> storing systemd service files in different folders underneath /home
> and provide them to systemd using "systemctl enable ..." with the
> absolute path to the file.
> 
> This approach doesn't work during boot, because /home is mounted after
> systemd recognized its service files in "/etc/systemd/systemd". After
> boot, "systemctl status ..." with one of my services tells that the
> service is not loaded because the file is not found.
> 
> One way to work around that seems to be using user configs. Another
> thing I just tested is creating foo.path and foo.service in /, while
> foo.path observes that /home/... is available. If thats the case,
> foo.service is started and issues a "systemctl daemon-reload". That at
> least allows all the services formerly not loaded to be properly
> loaded. The only thing missing is starting the services, but that
> could be managed in some script or whatever.
> 
> While this works in my test-VM, the docs regarding this command read
> a bit scary:
> 
>> Reload the systemd manager configuration. This will rerun all
>> generators (see systemd.generator(7)), reload all unit files, and
>> recreate the entire dependency tree.
> 
> Could executing "daemon-reload" during boot break things terribly or
> could this be considered somewhat safe?
> 

While this is supposed to be transparent, there were quite some issues
due to incomplete save/restore of systemd state across daemon-reload,
some fixed, some may not. One example that to my best knowledge is not
yet fixed is "systemctl start/stop" being terminated by concurrent
daemon-reload, thus not waiting for completion. Another problem (that
could really bite during startup) was that on daemon-reload systemd
"forgot" current ExecStart directive and executed them from the very
beginning. See also
https://lists.freedesktop.org/archives/systemd-devel/2018-January/040269.html

So your systemd version used by your distribution may have various
problems that may cause some "interesting" issues. I'd say it is better
to avoid it if at all possible.

One thing that may work - create service WantedBy and After home.mount,
that contains ExecStart=systemctl --no-block start
your-file-on-home.service. systemd should rescan for unit definitions
and should find them now when /home is mounted.