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