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

[Jérémy ROSEN]

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

daemon.service : the service you are trying to delay
trigger_file : the file created by dhclient

moreover you want daemon.service to be part of the startup transaction (I'm
not certain why) and not triggered on the file creation as a .path unit
would do.

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.


a .path would be a slightly different way of doing it that would not be
limited to the startup phase, but again i'm not completely sure what you
are trying to do

HTH
Jeremy

Le lun. 19 août 2019 à 14:49, Colin Hogben <systemd at pythontech.co.uk> a
écrit :

> Hi,
> (Hoping this is an appropriate place to ask this question...)
>
> During system start-up, I want to defer starting a unit (a service)
> until a particular file is written (amongst other dependencies).  In
> my case I am writing the service's configuration file within a
> dhclient hook script.
>
> Any guidance on achieving this with systemd would be much appreciated.
>
> I don't think a .path unit is the appropriate tool for the job, since
> AIUI that is intended to start a new systemd transaction rather than
> for scheduling within an existing transaction.  I tried having my
> service depend on (via Requires/After) the foo.unit related to
> foo.path, but then systemd starts foo.unit straight away regardless of
> foo.path.  If I have After=foo.unit and Requires=foo.path, then it seems
> like foo.unit is not "pulled in", and the After has no effect.  But
> maybe I missed something.
>
> The .path causes its related unit to start, whereas I think I want to
> provoke a transition in a unit from startING to startED - am I right?
>
> I thought of using the 'inotify' executable within a unit upon which
> my service could depend.  Unfortunately, CentOS (& Redhat) in their
> wisdom decided not to package inotify-tools.
>
> Thanks for any help,
> --
> Colin Hogben
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
[image: SMILE]  <http://www.smile.eu/>

20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique

[image: email] jeremy.rosen at smile.fr
[image: phone]  +33 6 88 25 87 42
[image: url] http://www.smile.eu

[image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
<https://www.facebook.com/smileopensource> [image: LinkedIn]
<https://www.linkedin.com/company/smile> [image: Github]
<https://github.com/Smile-SA>

[image: Découvrez l’univers Smile, rendez-vous sur smile.eu]
<https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20190820/8cdf0cab/attachment-0001.html>