Re: Deferring start of service until file exists

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine

Jérémy ROSEN
Architecte technique

email jeremy.rosen@xxxxxxxx 
phone  +33 6 88 25 87 42 
url http://www.smile.eu

Twitter Facebook LinkedIn Github

Découvrez l’univers Smile, rendez-vous sur smile.eu
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux