[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: launchd port: Worth it?
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>
Main Index |
Thread Index |