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

[Reindl Harald]

Am 21.08.19 um 06:34 schrieb Reindl Harald:
> Am 21.08.19 um 06:10 schrieb Mantas Mikulėnas:
>> On Tue, Aug 20, 2019, 20:43 Reindl Harald > > wrote:
>>
>> Am 20.08.19 um 18:56 schrieb Boyce, Kevin P [US] (AS):
>> > If this gets figured out, I would love to know how to do it as well.
>> >
>> > My experience with systemd is that it will proceed to start other
>> services once the dependencies have started, not necessarily exited.
>>
>> no
>>
>> that's only true for Type=simple or for broken services which are
>> forking too soon
>>
>>
>> As written it's probably true for all types except Type=oneshot, I think
>> that's what was meant by "exited". (I.e. not "daemonized")
> 
> hell no, oneshot orders too and it's even easier becaue it exists
> completly and it takes you just 30 seconds to try it out or a little
> expierience with systemd at all
> 
> the only thing where systemd can't wait is "simple" because there is no
> forking and no exit and so systemd can't tell if the executeable is full
> opertional
> 
> oneshot: no-brainer, ExecStart exists, next prdered service
> forking: doble fork of ExecStart, next orderred service
> notify:  mainpid even tells systemd "im ready, you can continue"

Type=oneshot
RemainAfterExit=yes

that way the reverse ordering at shutdown even works fine
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Reindl Harald]

Am 21.08.19 um 06:10 schrieb Mantas Mikulėnas:
> On Tue, Aug 20, 2019, 20:43 Reindl Harald  > wrote:
> 
> 
> 
> Am 20.08.19 um 18:56 schrieb Boyce, Kevin P [US] (AS):
> > If this gets figured out, I would love to know how to do it as well.
> >
> > My experience with systemd is that it will proceed to start other
> services once the dependencies have started, not necessarily exited.
> 
> no
> 
> that's only true for Type=simple or for broken services which are
> forking too soon
> 
> 
> As written it's probably true for all types except Type=oneshot, I think
> that's what was meant by "exited". (I.e. not "daemonized")

hell no, oneshot orders too and it's even easier becaue it exists
completly and it takes you just 30 seconds to try it out or a little
expierience with systemd at all

the only thing where systemd can't wait is "simple" because there is no
forking and no exit and so systemd can't tell if the executeable is full
opertional

oneshot: no-brainer, ExecStart exists, next prdered service
forking: doble fork of ExecStart, next orderred service
notify:  mainpid even tells systemd "im ready, you can continue"
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Mantas Mikulėnas]

On Tue, Aug 20, 2019, 20:43 Reindl Harald  wrote:

>
>
> Am 20.08.19 um 18:56 schrieb Boyce, Kevin P [US] (AS):
> > If this gets figured out, I would love to know how to do it as well.
> >
> > My experience with systemd is that it will proceed to start other
> services once the dependencies have started, not necessarily exited.
>
> no
>
> that's only true for Type=simple or for broken services which are
> forking too soon
>

As written it's probably true for all types except Type=oneshot, I think
that's what was meant by "exited". (I.e. not "daemonized")
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Need help detecting local/remote targets

[Mantas Mikulėnas]

On Wed, Aug 21, 2019, 01:15 Tony Rodriguez  wrote:

> I modified systemd-219 functionality to meet a custom requirement for
> detecting filesystems/devices that use iscsi without using the _netdev
> keyword in /etc/fstab.  It is a strict requirement regarding not using
> _netdev that I have no control over.   However,  I am stuck.
>
>  From my understanding, src/fstab-generator.c is used to determine
> LOCAL-FS and REMOTE-FS.  I have modified fstab-generator.c to search for
> iscsi udev devices which works, provided the system is already fully
> booted (typical multi-user state type of thing).  I can also find
> /dev/disk/ block devices including iscsi devices using my logic within
> fstab-generator.c.  The problem is when the system reboots, it appears
> systemd using the same fstab-generator logic that I implemented is
> unable to detect any iscsi devices.  After doing some research, it
> appears normal systemd behavior is to mount  /  and /usr then invoke
> fstab-generator.c to determine if a given filesystem in /etc/fstab
> should be a local or remote target.
>

/ and /usr are mounted by initramfs before systemd starts.

(If your initramfs itself uses systemd, that's mostly independent from the
main-root systemd – they're two separate worlds.)


> The problem is I have no way to tell if a given iscsi filesystem/device
> specified in /etc/fstab (without the _netdev keyord ) is local/remote
> during the booting state.  Mainly because devices are not yet populated
> in /dev/disk or udev.  Is there a way I can determine if a
> filesystem/mount point/device specified in /etc/fstab is local or remote
> without the _netdev or fstype (which handles nfs, etc) keywords within
> fstab-generator.c?


By design, generators run before any services have started, so no udev yet.

(But if you had udev in the initramfs, it could store data in /run that you
could then read from a generator.)

If checking udev and /dev/disk are not possible
> within fstab-generator.c, because such devices are not yet populated,
> then what should I modify within the systemd source so I can determine
> such local/remote targets myself and pass it to fstab-generator.c
> (especially when the system is in that / and /usr mounting state and
> udev devices are not yet populated?
>

If you can't use _netdev, then use custom options. Fstab now supports
arbitrary "x-" prefixed options, and systemd fstab generator already
recognizes several such as "x-systemd.requires=iscsid-is-ready.target". (I
think they're listed in the systemd.mount manpage?)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Help: Local and Remote targets

[Tony Rodriguez]

Understood but I don't have to worry about iscsi offloading for now.   
Some theories I have to attack the problem but each has a problem and 
may be complex.


1) Since I can obtain udev/disk information when the system is in a 
multi-user already booted stated.  Check for "iscsi" devices and 
filesystems then create a file on "/" that has the device id and specify 
it as an iscsi device.  When the system reboots then check for that 
file, if it exists set state to REMOTE-FS target within fstab-generator.c


Problem:  I will have to manage create/remove such files within systemd 
especially if contents within /etc/fstab are manually modified by the 
user.  Where would be the best place to put such logic within systemd 
source?


2) Boot the system mounting only "/" and "/usr" and defer 
fstab-generatoration until the system is booted.  Then find a way to 
manually re-start fstab-generation after iscsi/network are operational.  
After that restart systemd.


Problem: Unsure if this is reasonable. Wondering if doing so may 
introduce some kind of side effect issues regarding mounting and other 
services.


Note:
Really hoping for an easier way instead of trying to implement points 
(1) or (2)


Tony

On 8/20/19 3:33 PM, Rick Beldin wrote:

This might be problematic.  What will you do with iscsi devices that support
iscsi offload?  Those are typically completely invisible to the OS and just
appear as another HBA.

On 8/20/19 3:26 PM, Tony Rodriguez wrote:

I modified systemd-219 functionality to meet a custom requirement for
detecting filesystems/devices that use iscsi without using the _netdev keyword
in /etc/fstab.  It is a strict requirement regarding not using _netdev that I
have no control over.   However,  I am stuck.

 From my understanding, src/fstab-generator.c is used to determine LOCAL-FS and
REMOTE-FS.  I have modified fstab-generator.c to search for iscsi udev devices
which works, provided the system is already fully booted (typical multi-user
state type of thing).  I can also find /dev/disk/ block devices including
iscsi devices using my logic within fstab-generator.c.  The problem is when
the system reboots, it appears systemd using the same fstab-generator logic
that I implemented is unable to detect any iscsi devices.  After doing some
research, it appears normal systemd behavior is to mount  /  and /usr then
invoke fstab-generator.c to determine if a given filesystem in /etc/fstab
should be a local or remote target.

The problem is I have no way to tell if a given iscsi filesystem/device
specified in /etc/fstab (without the _netdev keyord ) is local/remote during
the booting state.  Mainly because devices are not yet populated in /dev/disk
or udev.  Is there a way I can determine if a filesystem/mount point/device
specified in /etc/fstab is local or remote without the _netdev or fstype
(which handles nfs, etc) keywords within fstab-generator.c? If checking udev
and /dev/disk are not possible within fstab-generator.c, because such devices
are not yet populated, then what should I modify within the systemd source so
I can determine such local/remote targets myself and pass it to
fstab-generator.c (especially when the system is in that / and /usr mounting
state and udev devices are not yet populated?

Thanks,
Tony
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Help: Local and Remote targets

[Rick Beldin]

This might be problematic.  What will you do with iscsi devices that support
iscsi offload?  Those are typically completely invisible to the OS and just
appear as another HBA.

On 8/20/19 3:26 PM, Tony Rodriguez wrote:
> I modified systemd-219 functionality to meet a custom requirement for
> detecting filesystems/devices that use iscsi without using the _netdev keyword
> in /etc/fstab.  It is a strict requirement regarding not using _netdev that I
> have no control over.   However,  I am stuck.
> 
> From my understanding, src/fstab-generator.c is used to determine LOCAL-FS and
> REMOTE-FS.  I have modified fstab-generator.c to search for iscsi udev devices
> which works, provided the system is already fully booted (typical multi-user
> state type of thing).  I can also find /dev/disk/ block devices including
> iscsi devices using my logic within fstab-generator.c.  The problem is when
> the system reboots, it appears systemd using the same fstab-generator logic
> that I implemented is unable to detect any iscsi devices.  After doing some
> research, it appears normal systemd behavior is to mount  /  and /usr then
> invoke fstab-generator.c to determine if a given filesystem in /etc/fstab
> should be a local or remote target.
> 
> The problem is I have no way to tell if a given iscsi filesystem/device
> specified in /etc/fstab (without the _netdev keyord ) is local/remote during
> the booting state.  Mainly because devices are not yet populated in /dev/disk
> or udev.  Is there a way I can determine if a filesystem/mount point/device
> specified in /etc/fstab is local or remote without the _netdev or fstype
> (which handles nfs, etc) keywords within fstab-generator.c? If checking udev
> and /dev/disk are not possible within fstab-generator.c, because such devices
> are not yet populated, then what should I modify within the systemd source so
> I can determine such local/remote targets myself and pass it to
> fstab-generator.c (especially when the system is in that / and /usr mounting
> state and udev devices are not yet populated?
> 
> Thanks,
> Tony
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 

-- 
Rick Beldin
HPE Master Technologist, ERT
HPE Pointnext
Tel:  +1 470 2129073  Email: rick.bel...@hpe.com
Physical: 8000 Foothills Blvd. | Roseville, CA 95747 Hewlett Packard Enterprise
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Help: Local and Remote targets

[Tony Rodriguez]

I modified systemd-219 functionality to meet a custom requirement for 
detecting filesystems/devices that use iscsi without using the _netdev 
keyword in /etc/fstab.  It is a strict requirement regarding not using 
_netdev that I have no control over.   However,  I am stuck.


From my understanding, src/fstab-generator.c is used to determine 
LOCAL-FS and REMOTE-FS.  I have modified fstab-generator.c to search for 
iscsi udev devices which works, provided the system is already fully 
booted (typical multi-user state type of thing).  I can also find 
/dev/disk/ block devices including iscsi devices using my logic within 
fstab-generator.c.  The problem is when the system reboots, it appears 
systemd using the same fstab-generator logic that I implemented is 
unable to detect any iscsi devices.  After doing some research, it 
appears normal systemd behavior is to mount  /  and /usr then invoke 
fstab-generator.c to determine if a given filesystem in /etc/fstab 
should be a local or remote target.


The problem is I have no way to tell if a given iscsi filesystem/device 
specified in /etc/fstab (without the _netdev keyord ) is local/remote 
during the booting state.  Mainly because devices are not yet populated 
in /dev/disk or udev.  Is there a way I can determine if a 
filesystem/mount point/device specified in /etc/fstab is local or remote 
without the _netdev or fstype (which handles nfs, etc) keywords within 
fstab-generator.c? If checking udev and /dev/disk are not possible 
within fstab-generator.c, because such devices are not yet populated, 
then what should I modify within the systemd source so I can determine 
such local/remote targets myself and pass it to fstab-generator.c 
(especially when the system is in that / and /usr mounting state and 
udev devices are not yet populated?


Thanks,
Tony
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Need help detecting local/remote targets

[Tony Rodriguez]

I modified systemd-219 functionality to meet a custom requirement for 
detecting filesystems/devices that use iscsi without using the _netdev 
keyword in /etc/fstab.  It is a strict requirement regarding not using 
_netdev that I have no control over.   However,  I am stuck.


From my understanding, src/fstab-generator.c is used to determine 
LOCAL-FS and REMOTE-FS.  I have modified fstab-generator.c to search for 
iscsi udev devices which works, provided the system is already fully 
booted (typical multi-user state type of thing).  I can also find 
/dev/disk/ block devices including iscsi devices using my logic within 
fstab-generator.c.  The problem is when the system reboots, it appears 
systemd using the same fstab-generator logic that I implemented is 
unable to detect any iscsi devices.  After doing some research, it 
appears normal systemd behavior is to mount  /  and /usr then invoke 
fstab-generator.c to determine if a given filesystem in /etc/fstab 
should be a local or remote target.


The problem is I have no way to tell if a given iscsi filesystem/device 
specified in /etc/fstab (without the _netdev keyord ) is local/remote 
during the booting state.  Mainly because devices are not yet populated 
in /dev/disk or udev.  Is there a way I can determine if a 
filesystem/mount point/device specified in /etc/fstab is local or remote 
without the _netdev or fstype (which handles nfs, etc) keywords within 
fstab-generator.c? If checking udev and /dev/disk are not possible 
within fstab-generator.c, because such devices are not yet populated, 
then what should I modify within the systemd source so I can determine 
such local/remote targets myself and pass it to fstab-generator.c 
(especially when the system is in that / and /usr mounting state and 
udev devices are not yet populated?


Thanks,
Tony
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Reindl Harald]

Am 20.08.19 um 18:56 schrieb Boyce, Kevin P [US] (AS):
> If this gets figured out, I would love to know how to do it as well.
> 
> My experience with systemd is that it will proceed to start other services 
> once the dependencies have started, not necessarily exited.

no

that's only true for Type=simple or for broken services which are
forking too soon
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Boyce, Kevin P [US] (AS)]

If this gets figured out, I would love to know how to do it as well.


Basically what you are looking for is some sort of a flag that until created by 
some process prevents systemd from starting other processes until this one very 
special process you have written completes and flips the flag to continue 
booting?  You expect to be able to create a unit file that has the Before= and 
After= right when you want your process to start.

My experience with systemd is that it will proceed to start other services once 
the dependencies have started, not necessarily exited.

Kevin

From: systemd-devel  on behalf of 
Colin Hogben 
Sent: Tuesday, August 20, 2019 10:32 AM
To: Jérémy ROSEN
Cc: systemd Mailing List
Subject: EXT :Re: [systemd-devel] Deferring start of service until file exists

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.

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.

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.

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.

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

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

> 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.  Thanks
for the suggestions.

--
Colin Hogben
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

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

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.

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.

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.

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.


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.

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.  Thanks
for the suggestions.

--
Colin Hogben
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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



-- 
[image: SMILE]  

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

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

[image: Twitter]  [image: Facebook]
 [image: LinkedIn]
 [image: Github]


[image: Découvrez l’univers Smile, rendez-vous sur smile.eu]

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel