Re: daemontools respin?

On Wed, 9 Jun 2010 12:04:44 -0600
Bruce Guenter <[email protected]> wrote:

> On Wed, Jun 09, 2010 at 05:16:48PM +0000, Wayne Marshall wrote:
> > Bruce Guenter <[email protected]> wrote:
> > 
> > > After hearing talk about some new ideas being thrown around
> > > for new init programs and other supervisory agents, I have
> > > been thinking about making some enhancements to
> > > daemontools.
> > 
> > Have you looked at perp (http://b0llix.net/perp/):
> 
> No, in fact I had never heard of it.  Some more interesting
> ideas to consider.  Have you by any chance used an Amiga in
> your past?
> 
> I should have said up front, that one of my goals is to, as
> much as possible, leave the resulting programs as drop-in
> replacements for current daemontools.  Kindof a daemontools++.
>

It is trivial to drop any existing daemontools service
definitions into a perp installation. See the COMPATIBILITY
section in perpetrate(5) for examples.
 
> >   * easy configuration: in place service activation and no
> >       symlinks!
> 
> I've read some of the man pages, but I'm not clear how you can
> put a service into place into /etc/perp without having it
> start automatically when perpd is HUPped.
>

Service installation:

 # cd /etc/perp
 # mkdir myservice
 # ... (install rc.main, rc.log, etc.)

Supervisor perpetrate(8) will not be started until service is
explicitly activated (example below assumes perpd(8) is running
in autoscan mode):

 # perpls myservice
 [- --- ---]  myservice
 # chmod +t myservice
 # perpls myservice
 [+ +++ +++]  myservice  uptime: 1s/1s  pids: 13490/483

> >   * pretty good troff -man documentation
> 
> Check. :)
> 
> > > - Support for explicit one-shot services, having "start"
> > > and "stop" scripts but no "run".
> > 
> > Check (flag.once).
> 
> My plans are to be at least a little more flexible than this
> -- to allow start and stop *with* standard run as well, so as
> to handle any permutation of the 3 being present (except
> possibly only stop scripts)
>

See perpctl(8).
 
> > > - Support for delayed startup and dependencies in svscan.
> > 
> > Check (perpok(8)).
> 
> The plan is to handle this entirely within svscan, to
> eliminate services having to poll other services.  Are you up
> yet?  Are you up yet?
>

perp is designed specifically to attain and maintain a state of
persistence.  It provides event handling for both start and reset
events.  Although not specifically documented, multiple
interdependent perp trees/chains can be installed and configured
by the administrator.  This flexibility is generally sufficient
to resolve most problems of supervision, and runtrap(8),
runpause(8), and perpok(8) are also available for special needs.

Failing on a missing dependency is actually logical.  The reset
event handler then enables notification and/or branch to other
action as configured by the administrator.

> > > - Support for storing the "supervise" files in an alternate
> > > location so as to allow services on read-only filesystems.
> > 
> > Check.  All runtime control files configured by default
> > to symlink on /var/run/perp/ (for possible setup on mfs),
> > while /etc/perp itself remains pristine and can be mounted
> > fully read-only in usual operation.
> 
> Yeah, I'm still trying to figure out the best way to do this
> (while still maintaining some semblance of backwards
> compatibility).
> 
> > > - Automatic setuid support in supervise.
> > 
> > Well, not sure what "automatic" means here.
> 
> My idea was that if the service directory was owned by
> non-root, to setuid to the owner after changing into the
> directory; and/or if the "run" file was owned by non-root, to
> setuid to the owner after forking.
> 

Well, the use case here still seems a little ambiguous.
Generally, I think it would be inadvisable to have
non-root-owned service directories under a root-priveleged
svscan, unless the entire svscan instance/tree were
non-priveleged.  Under root-owned service trees, the
administrator has tools like runtool(8) and runuid(8) available
for runscript control.  However, it may be that some additional
runtool would serve your needs, one which inspected the ownership
of some target directory, then running the service under that
uid.  Would that do it?

Cheers,

Wayne