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

[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 ...

> 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...)

> 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.

> 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

>>> 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.

>> 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?

-- 
Colin Hogben