[systemd-devel] Deferring start of service until file exists

[Silvio Knizek]

Am Dienstag, den 20.08.2019, 16:32 +0100 schrieb Colin Hogben:
> 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.
Try to solve one problem at a time. Even if problems seems to be
similiar the can need different solutions.
>
> 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.
The NFS root needs to be mounted in the initrd step. Else everything
will break. With systemd in the initrd you gain the possibilty to
depend on those units in the actual system.
>
> 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.
Why not systemd-networkd, systemd-journald with remote-forwarding
enabled and systemd-timesyncd?
>
> 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.
Than your dhclient should start the network-online.target and you
should order everything accordingly. Or you use systemd-networkd which
already have a systemd-networkd-wait-online.service
>
> > 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.
But the trigger for the .service is not start up, but accessibilty and
if certain information are available.
>
> > 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.
There are the proper dependencies. If you need network, there is the
network-online.target.
>
> > 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.
You don't have to reinvent the wheel. You just need to know about the
capabilities of systemd.
> Thanks for the suggestions.