Importing djb's public domain daemontools?

[Jos Backus]

Hi Doug,

On Mon, Jan 16, 2012 at 9:10 PM, Doug Barton <dougb at freebsd.org> wrote:

> On 01/16/2012 19:41, Jos Backus wrote:
> > On Jan 16, 2012 6:53 PM, "Doug Barton" <dougb at freebsd.org> wrote:
> >>
> >> On 01/16/2012 12:53, Jos Backus wrote:
> >>>
> >>> Thoughts?
> >>
> >> This is already available in ports.
> >
> > I realize that.
>
> Good, then we're done. :)
>

Heh :)


>
> > If FreeBSD had a solid solution out of the box, all this pidfile hackery
> in
> > the base system wouldn't be necessary.
>
> We don't do religious wars here. We especially don't do trollbait from
> djb acolytes. The "pidfile hackery" that we currently have works just
> fine in the vast majority of cases. The fact that it doesn't meet some
> people's ideas of architectural purity is totally beside the point.
>
>
I want/need a solution that works in (nearly) all cases and is devoid of
complex code trying to track state that is already represented elsewhere in
the system (the process table and the parent/child process relationship). I
want a solution that can reliably handle a crashing server that doesn't
clean up its pidfile (the finish script functionality in daemontools-encore
provides this), and I want a unified control interface for the services
running on a box, a la launchd or what have you. This isn't about religion
but about missing base system functionality - the ability to reliably
control services running on a box.



> > I always thought FreeBSD was about
> > good engineering. Perpetuating the pidfile mess in the base is not a sign
> > of good engineering.
>
> FreeBSD is about giving people choices. Those who want to use
> daemontools can do that.
>

I thought the motto was  "tools, not policies" ;)


>
> And lest people think that I'm just hating on daemontools, I'm not. I
> use it for some things. But converting everything in the base to use it
> is a non-starter, even if we wanted to import it, which I don't see any
> need to do.
>

Straw man. I'm asking for FreeBSD to *support* this functionality out of
the box, just like OS X, Solaris, AIX and some Linux versions (with
systemd). The closest FreeBSD has today is init, and it's not flexible
enough to do the job.

ISTR the last time I mentioned this, the debate was all about the code's
license, not about the functionality. I'm glad we at least now can discuss
whether this functionality belongs in the base system, as the license
should no longer be an issue (it's public domain).

Jos

-- 
Jos Backus
jos at catnook.com