Re: daemontools respin?

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++.

>   * 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.

>   * 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)

> > - 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?

> > - 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.

-- 
Bruce Guenter <[email protected]>                http://untroubled.org/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)

iEYEARECAAYFAkwP17wACgkQ6W+y3GmZgOjXFACfX7J1CfjZ9f1iDb5fTRisaa/1
lukAn3DSa6wL06aosjrvlJLvmAXt9Bda
=mMb8
-----END PGP SIGNATURE-----