Importing djb's public domain daemontools?

Jos Backus jos at catnook.com
Tue Jan 17 21:54:07 UTC 2012


2012/1/17 Dag-Erling Smørgrav <des at des.no>

> Jos Backus <jos at catnook.com> writes:
> > 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).
>
> Please show me the complex code required to handle pidfiles.
>

In my solution, no such code exists, so whatever code is there now (the
pidfile library/API) is more complex by definition :)


>
> > I want a solution that can reliably handle a crashing server that
> > doesn't clean up its pidfile
>
> That's a strawman.  Whatever tool you use needs to be able to handle
> stale pidfiles anyway.
>

Um, why? The solution I propose doesn't use pidfiles at all.


>
> > I want a unified control interface for the services running on a box,
> > a la launchd or what have you.
>
> So extend service(8) to support enabling / disabling services through
> /etc/rc.conf.d/<servicename>.  Probably no more than an afternoon's
> work.
>
> > This isn't about religion but about missing base system functionality
> > - the ability to reliably control services running on a box.
>
> The onus is on you to show that we don't already have that.
>

As I said before, the only thing we have today that will automatically
restart services is init, and it is not flexible enough. That's where
launchd would come in, but that would be a much more invasive change than
just adding the daemontools bits, which would be optional and could be
integrated gradually.

Jos


> DES
> --
> Dag-Erling Smørgrav - des at des.no
>



-- 
Jos Backus
jos at catnook.com


More information about the freebsd-arch mailing list