Re: [announce] perp-2.03: persistent process supervision

[Wayne Marshall <wcm@b0llix.net>]

On Mon, 14 Mar 2011 11:03:45 -0400 (EDT)
Charlie Brady <charlieb-supervision@budge.apana.org.au> wrote:

> 
> On Mon, 14 Mar 2011, Robin Bowes wrote:
> 
> > On 14/03/11 14:02, Wayne Marshall wrote:
> > 
> > > Under normal (default) configurations, whenever perpd(8)
> > > terminates it is restarted by either perpboot(8), or
> > > init(8) with a "respawn" configuration in inittab(5).
> > > perpd(8) then restarts all services marked for activation
> > > in /etc/perp.
> > 
> > So, if I have a service that is normally running, ie. starts
> > at boot, but I have taken it down manually for whatever
> > reason, and perpd dies, then my service will also be
> > re-started?
> 
> And presumably the converse will apply as well. This is a
> problem with runit (and daemontools) - if a service has a
> 'down' file, but has been later started, a dying runsv (e.g.
> if killed by the OoM killer, or by a service which kills its
> process group) will be replaced by runsvdir, but the service
> will stay down.
> 

This is not so much a "problem" of design, but rather of
adminsistrative clarity.

Use "flag.down" only when you don't want a service to start
immediately with perpd, but do want it activated and available to
perpctl administration.

As an example, I use a wpa_supplicant service definition on my
laptop.  It is defined with "flag.down", because I don't care for
a wireless connection in all circumstances.  Other network
scripts may then call:

  perpctl up wpa_supplicant

or

  perpctl down wpa_supplicant

as necessary.

Otherwise -- and generally for any truly persistent process
service -- administrators will avoid using the "flag.down"
mechanism in favor of the easy, in-place service
activation/deactivation mechanism that perpd provides with the
service directory sticky bit.

Wayne