Re: EXT :Re: Deferring start of service until file exists

["Boyce, Kevin P [US] (AS)" <Kevin.Boyce@xxxxxxx>]

If this gets figured out, I would love to know how to do it as well.


Basically what you are looking for is some sort of a flag that until created by some process prevents systemd from starting other processes until this one very special process you have written completes and flips the flag to continue booting?  You expect to be able to create a unit file that has the Before= and After= right when you want your process to start.

My experience with systemd is that it will proceed to start other services once the dependencies have started, not necessarily exited.

Kevin
________________________________________
From: systemd-devel <systemd-devel-bounces@xxxxxxxxxxxxxxxxxxxxx> on behalf of Colin Hogben <systemd@xxxxxxxxxxxxxxxx>
Sent: Tuesday, August 20, 2019 10:32 AM
To: Jérémy ROSEN
Cc: systemd Mailing List
Subject: EXT :Re:  Deferring start of service until file exists

Hi Jérémy, thanks for responding.

> I'm not very clear on what you are trying to do, so if my understanding
> is correct:

OK, I'll try to clarify.  In fact I'm lumping together several similar
circumstances.  It's possible that for at least some of these, I'm not
thinking about things in the right way.

The broader context is a diskless server (NFS root) with potentially
several instances whose configuration is managed through DHCP and/or
kernel command-line options.

One case is that I want to run rsyslogd with messages forwarded to an
external server.  The server address is configured via a standard DHCP
option.  My idea was to defer starting rsyslogd until the
configuration had been set via the dhclient hook script.  On
reflection, perhaps the dhclient script could do a "systemctl
reload-or-try-restart rsyslog".  Another very similar case is time
synchronisation, using chronyd.

But now we come to the nitty-gritty.  My application needs to interact
with a hardware device and also needs some info from DHCP (essentially
which hosts are allowed to talk to it).  In addition, the application
executable and libraries are on a filesystem mounted from a location
derived from DHCP.

> moreover you want daemon.service to be part of the startup transaction
> (I'm not certain why)

Well, I'm not sure why I wouldn't.  The whole purpose of the system is
to run that service.

> and not triggered on the file creation as a .path
> unit would do.

One key point is that there are other dependencies.

My hope was that I would be able to implement most of this in the
systemd declarative style - the application depends on a device, on
the existence of a file and on a mounted filesystem.  I don't
necessarily know in which order these things will appear, but systemd
should sort it all out for me.

> I would create an intermediate service wait_for_file.service that would
> be Type=oneshot and would simply trigger some sort of shell script
> waiting for trigger_file to appear and the terminate.
>
> daemon.service would have Wants=wait_for_file and After=wait_for_file
> and you should be good.

Having to write looping shell-scripts or reinvent inotifywait seems
contrary to the spirit of systemd, but maybe I have to do that.  Thanks
for the suggestions.

--
Colin Hogben
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel