Just throwing out a few factoids pertaining to perp:
In general, so-called "one-shot" thingies are by definition not services
(that is, are not persistent processes), and so are not properly in the
domain of supervision.
But perp does accomodate various permutations and monstronsities as are
under discussion here.
1) the runpause(8) utility may be used to hack a service out of what
normally would be a system initialization:
http://b0llix.net/perp/site.cgi?page=runpause.8
Note also: perpd runs as a single daemon and does not "spawn" a useless
forest of additional supervise process overhead.
2) the 'flag.once' mechanism in a service directory may be used to mark
a service at start-up for running only once -- see the STARTUP
MODIFICATION section of the perpd(8) manual:
http://b0llix.net/perp/site.cgi?page=perpd.8
3) there is no rule that limits one to running only a single perpd
instance. It is possible to run multiple perpd instances on a single
system to segregate services in a way roughly analogous to sysv
runlevels, and I have done so.
4) in general, folks here are letting their panties get far too twisted
with the dependency problem. Actual material dependencies are
relatively few and can be easily (and best) accomodated directly in the
runscript of the dependent service. See the perpok(8) utility for a
way to handle dependencies that is suitable in practice for most all
installations:
http://b0llix.net/perp/site.cgi?page=perpok.8
Wayne
http://b0llix.net/perp/
On Wed, 21 Jan 2015 17:26:45 -0500
Steve Litt <slitt_at_troubleshooters.com> wrote:
> On Wed, 21 Jan 2015 20:23:22 +0100
> Laurent Bercot <ska-supervision_at_skarnet.org> wrote:
>
> > On 21/01/2015 19:03, Steve Litt wrote:
> >
> > > 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.
> >
> > That's really using a supervision infrastructure for things it was
> > not made for. You don't want to spawn a s6-supervise process for
> > every one-shot script you're running!
>
> My use case would be something like this: perhaps
> mySpecialConfigScript, which gets run once and terminates after doing
> its job, must be run at boot but depends on mySpecialDaemon, which is
> managed by, let's say, s6-supervise. I can't put mySpecialConfigScript
> in phase 1 because it requires mySpecialDaemon, which is phase 2.
>
> So anyway, this would be done only for the few one-shot processes that
> require a certain daemon running. One-shots with no daemon
> dependencies can be done in phase 1, no problem.
>
> But at least, if I *absolutely must* run a one-shot, on boot, that
> depends on a daemon, I have a way of doing it which involves no change
> to the current runit, s6, nosh or (as far as I know) perp programs.
>
> Thanks,
>
> SteveT
>
> Steve Litt * http://www.troubleshooters.com/
> Troubleshooting Training * Human Performance
>
>
Received on Wed Jan 21 2015 - 23:09:40 UTC