Discussion:
Is it safe to issue "systemctl daemon-reload" during boot?
Add Reply
Thorsten Schöning
2018-05-04 14:32:55 UTC
Reply
Permalink
Raw Message
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
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?

Thanks!

Mit freundlichen Grüßen,

Thorsten Schöning
--
Thorsten Schöning E-Mail: ***@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Andrei Borzenkov
2018-05-04 17:42:04 UTC
Reply
Permalink
Raw Message
Post by 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
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.

Loading...