On 01/21/15 19:03, Steve Litt wrote:
> On Wed, 21 Jan 2015 18:24:58 +0100
> Olivier Brunel <jjk_at_jjacky.com> wrote:
>
>> Hi Laurent,
>>
>> So you mentioned breaking compatibility recently, and I figure that
>> might be a good time for me to mention something. I'd like to set up
>> my system around s6, and have been working on this lately.
>>
>> I'll have to setup some scripts for different init stages, using
>> s6-svscan as stage 2, as you've described elsewhere. But I also want
>> to have a system to start (and stop) services in order. I see this
>> whole idea of order/dependency is something that is being talked
>> about, but currently not supported.
>
> Can't you do something like this:
>
> http://smarden.org/runit/faq.html#depends
No. By which I mean, I do not want to use the run script to handle
dependency/order, for a few reasons.
Such as, I don't think it's its place; It makes things harder to
tweak/change, I'll simply use files in subfolder
needs/wants/after/before; It also produces things I don't like, where a
service is seen as up because its run script is indeed running, but the
service hasn't even began to start yet, as the run script is just
waiting for another service to be up.
I don't like that, I'd rather have something (i.e. external tool) start
one service, then waits until it's up to start the other one.
I feel a run script should only set things up (limits, environ, etc) and
exec into the actual service/daemon, nothing else. It should be as quick
as possible, much like the finish script is supposed to be (in s6, 5s
until it's killed).
>> Furthermore, I want this system of mine to include other kinds of
>> services, that is one-time process/scripts that needs to be run once
>> (on boot), and that's it. And to make things simpler, I want to have
>> it all work together, mixing longrun services (s6 supervised) and
>> oneshot services when it comes to dependency/order definition.
>
> I do too. If you have a run-once thing that quickly returns, couldn't
> you just not exec the thing in the run script, and then have the last
> statement in your run script write a "down" file to the service? I'm
> assuming that s6 does down files the same way as daemontools.
>
> Then, all that remains is to have stage 1 of your boot delete all the
> down files that were put there to achieve run-once.
Well, it might work, but it feels muck hackier to me. Not to mention a
down file means the service is meant to be down, whereas the oneshot
service would actually be meant to be up (and be active, as in it did
start and completed its run); Also that means a supervise running all
the time for no good reason for each oneshot service...
I don't like that.
> If it really is a daemon, but you don't want it respawned, couldn't you
> have the "finish" script (they have those in runit, I don't know about
> s6) write the "down" file?
>
> You know what you could do? You could make a $servicedir/oneshot
> shellscript that does something like this:
>
> touch ./down
> cat "rm $scriptname/down" >> $whatever/enable_oneshots.sh
>
> Then all you'd need to do is run $whatever/enable_oneshots.sh in stage
> 1, and right after that truncate and make executable
> $whatever/enable_oneshots.
>
> SteveT
>
> Steve Litt * http://www.troubleshooters.com/
> Troubleshooting Training * Human Performance
>
Received on Wed Jan 21 2015 - 18:31:33 UTC