> Am 01.02.2021 um 13:41 schrieb Laurent Bercot <ska-skaw...@skarnet.org>:
>> I'm struggling to figure out how to start a particular initialization when a 
>> service first comes up (since service startup, system startup, or ever).
>> I'm pretty sure it's well documented, but if the question is phrased 
>> incorrectly, you can search for a long time.
> Do you mean that the "start" script would only be run once, no matter
> how many times the service can die and be restarted later on?
> If so, it's the job of a service manager. Conceptually, "start" is
> not really part of the supervised service, it's something separate that
> needs to run before your service is first brought up.

Indeed - it could be part of the service manager ... I also try to draw
a line here.

In my particular use-case I (since s6-rc isn't packaged already) moved
it out to /etc/init.d/ but starting it like the example below to avoid
long hanging stage 2 start.

Since it's a `wait for device comes up` - a udev rule would be correct.

But another use-cause is:
* creating some file system entries first

> In the s6 world, this would be handled by s6-rc (or anopa). You would
> make a oneshot that contains your "start" script, and your longrun
> (containing your "run" script, the thing you want supervised) would
> depend on the "start" oneshot.
> But if it's not what you mean (and it appears it's not), read below.

Conceptional I mean:
1) start once when system starts - let service depend on it (as far as
   I understand, I need s6-rc for this) - maybe with support for systems
   without s6-rc for whatever reason.
2) start once every time $service is down and `s6-svc -[uo] $service`
   is invoked

I do not mean:
3) so something tidying before payload starts - this is the job of the
   run script.

>> What daemontools-encore does with ./start seems pretty ok - and would be 
>> near perfect if it were to wait for ./start to finish before running ./run.
> After reading
> https://untroubled.org/daemontools-encore/supervise.8.html
> I understand that ./start is run every time the service is started, not
> only the first time, and ./run is only actually executed if ./start
> exits 0. Which is a very different approach: "start" is not a
> oneshot, but part of the service.

I checked the source (since it behaved differently last time I used it)
and the appropriate code 
behaves that ./start is executed the very first time after `svc -[ou] 
is invoked. Any following service start (re-start after crash), just ./run ist 

Reading the man page from another perspective, this is also valid:
`svc -u $service`
 -> test -x $service/start && $service/start
    while true; do $service/run; done

> And if it's part of the service and supposed to be run every time,
> then you don't need a separate ./start: it can just as well be part
> of the ./run script.
> To emulate this in execline: if -X { ./start } rest-of-run-script
> and in shell: set -e ; ./start ; rest-of-run-script
>> s6 has a concept for ./finish - so I think a ./start concept is there as 
>> well and I just can't find it. Can someone please nudge me on this?
> ./finish has to be separate because it's spawned when ./run dies.
> But anything that needs to run *before* ./run can just be integrated
> into ./run instead, there's no need for a separate script.

Sure - ./finish is obvious - but there are reasons for 
so I wanted to know whether there is something and I'm unable to find it or
it's intentionally left out compared to daemontools-encore ;)

Jens Rehsack - rehs...@gmail.com

Attachment: signature.asc
Description: Message signed with OpenPGP

Reply via email to