> Would you then be in support of moving the pre/enable logic into a separate
> utility (something similar to `chpst)? So for example:
>
> runwith --ExecStartPre "mkdir /var/log/mysql" --ExecReload
> "/root/drain_reload.sh" mysqld
It is unclear to me whether the "pre" scripts are supposed to be
state-checked and maintained along with the long-lived process or
if they are supposed to be run only once; and I suspect different
script authors to have different expectations.
The thing is, everything that needs to be maintained should go into
the ./run script, because it is what the supervisor maintains. So if
you need to check that /var/log/mysql is present everytime, you should
add "mkdir -p /var/log/mysql" at the beginning of your ./run script.
And everything that needs not be maintained should be handled outside
of the supervisor, in a one-time script.
Supervisors only know one bit of information: is the long-lived process
alive or not ? They can't process states such as "the filesystem has been
correctly prepared but the daemon is currently down". So it's up to you
whether you want to maintain the whole state along with the daemon, or part
of the state, or nothing at all.
The issue I have with utilities such as your suggested "runwith" is
where and when you would run it. If your suggestion is to have SysV-style
(or OpenRC-style, or anything else of the kind) init scripts making calls
to "runwith", which would exec the right one-time stuff and also prepare the
appropriate directories to be supervised, then it's a totally valid approach,
but it needs support from the init system to actually launch a supervision
tree *prior to* running all those scripts, and also support in the supervision
system itself to avoid race conditions. This is my current plan for evolving
s6, but it's not there yet, and neither is runit; it's very doable, but you
can't just hack it in a day - it requires design to get things right and
adaptable to distributions' chosen ways of starting stuff. If that was not
your suggestion, then I'm confused about how this "runwith" command would
be used.
For now, I'd say you have to do things manually: analyze the "pre" stuff,
separate what needs to be run only once and what needs to be maintained,
move the run-once things into runit's stage 1, and move the maintained
things into ./run scripts. (Problems arise when you need to mix and match
run-once and maintained across different services; I've described this in
previous posts.)
> Alternatively, using current runit functionality, what would you think
> about if I simply add additional service directories that get loaded in
> order. So I could have all enable/pre scripts run as one-time runit
> services in a separate svdir:
You don't need a supervision tree for one-time stuff: those are all
short-lived processes. Just run the one-time scripts and be done with it.
--
Laurent
Received on Tue Oct 21 2014 - 20:02:53 UTC