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

[Silvio Knizek]

Am Mittwoch, den 21.08.2019, 09:32 +0100 schrieb Colin Hogben:
> On 20/08/19 16:54, Silvio Knizek wrote:
>
> > 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.
>
> Booting with an NFS root is working fine.  I'm not sure how to tell
> whether or not I have "systemd in the initrd" as you describe; I
> built the initrd with dracut, and I get the
>    random: systemd-udevd: uninitialized urandom read (16 bytes read)
> messages before
>    dracut: Mounted root filesystem ...
Ah, than it should be fine. dracut actually does it right®
>
> > Why not systemd-networkd,
>
> systemd-networkd is inadequate for the task.  Even though I could
> potentially parse the ntp servers out of the lease file (is that even
> a public interface with stable format?), I didn't find a way,
> documented or undocumented, for getting the log-server.  Indeed, from
> scanning the source code it seems that any DHCP options other than
> some core ones and those in the private range, e.g. 7 (log-server),
> are just ignored. (Bizarrely, systemd-networkd does include a DHCP
> server - WTF?! DOTADIW?  But I digress...)
sd-networkd would tell sd-timesyncd by themself. But yeah, currently
you can't add random options to the dhcp client.
>
> > systemd-journald with remote-forwarding
> > enabled
>
> I didn't know it could do that.  Googling e.g.
> https://unix.stackexchange.com/questions/394822 and the linked
> Redhat recommendation suggest otherwise.  I found references to
> systemd-journal-netlogd (WIP? PR #1890 rejected), and some other
> systemd stuff which didn't support traditional UDP output.
sd-journald would use it's own transport via HTTP(S). See man:systemd-
journal-gatewayd, man:systemd-journal-upload and man:systemd-journal-
remote
There are also other tools to directly read from the journal and into
the appropriate backend for elasticsearch, graylog and other.
>
> > and systemd-timesyncd?
>
> Only because it isn't (wasn't) packaged for CentOS 7.  In fact I used
> it  in another project and I'd forgotten I even found a way to
> integrate it with dhclient:
> https://www.raspberrypi.org/forums/viewtopic.php?t=217832
If you're stuck with dhclient and old versions of systemd, than use
ntpd or ntpdate, no problem.
>
> > > > 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.
>
> Other network-facing services e.g. sshd have WantedBy=multi-
> user.target - I don't see how my service is in principle
> different.  I just has some extra dependencies.
sshd.service is totaly fine by starting without network. It sounds like
your service needs a network and information from dhclient to be up
probably.
>
> > > 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.
>
> I'm trying to learn.  How can I get a systemd unit to defer its
> start until certain information is available from dhclient?
Well, in dhclient you can define a script which is executed as soon as
there is a lease. Use this to trigger further units as this is your
trigger. See man:dhclient-script
The normal start up logic is not appliable here. You want dhclient as
trigger after writing config files.