Re: launchd port: Worth it?

["Aaron B." <aaron%zadzmo.org@localhost>]

On Fri, 15 Mar 2013 11:11:31 -0400
Greg Troxel <gdt%ir.bbn.com@localhost> wrote:

> > Using a simple state machine and the code from rcorder to build a
> > dependancy graph I expect it could perform a parallelized
> > boot.
> 
> That sounds like a worthy goal.  Once there is code to run things in
> parallel (probably not too hard), I think we'll run into two problems:
> 
>   unexpressed dependencies, hidden by the standard serializaion order

I would consider that to be a bug in rc.d files, as it hasn't listed
it's dependancy explicitly.


>   daemons return before they are ready.  The rc.d script executes food,
>   and food does a double fork and the parent returns.  However, the
>   child is not ready to process events.  Arguably these issues should be
>   fixed in each daemon, having the parent wait for the child to signal
>   that it is finished initing.  I have seen this problem with iked/spmd
>   in racoon2, but I would be really surprised if we don't have instances
>   of it in-tree.  This is also covered up by the present system.

That I haven't thought of; and that isn't a bad way to handle it.

Another possiblity is that with the addition of the described
monitoring process, a simple 'heartbeat' library that the daemon could
hook into and tell the monitor it's ready to go. This would also allow
the monitor to kill and restart a seized process that's alive but no
longer able to do it's job, ie, stuck in an infinite loop.


> > However what I wanted was a system that restarts crashed daemons
> > and had an easy command line tool to monitor/enable or disable/etc
> > your processes, like the 'service' in Redhat or 'svcadm' in Solaris
> > 10, but more....  BSD.
> 
> I suppose it's not too hard to write something that does
> /etc/rc.d/status on various daemons, enabled by foo_monitor=YES in rc.d.
> 
> enable/disable seems like a script to edit the rc.conf file, or perhaps
> this gets pushed out to lightweight database (half joking there).

I envision rc.conf getting a lot smaller, as the process monitor keeps
track of what's enabled or disabled. And the tool talks via unix socket
or some other means to query current status, request a SIGHUP, disable
the service, or what have you.

-- 
Aaron B. <aaron%zadzmo.org@localhost>