Re: launchd port: Worth it?

"Aaron B." <aaron%zadzmo.org@localhost> writes:
> 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.
Agreed that it's just a bug, but I wanted to mention it since I think
we'll run into it.
>> 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.
I like the approach I described because it is useful without extra
infrastructure. Something as simple as
daemon1; daemon2
will ensure that daemon1 is ready to receive control messages sent by
daemon2, without having some other process wait for a message from
daemon1 and refraining from starting 2.
>> > 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.
You'll still need to record the desired flags, and all the stuff in
rc.conf that isn't daemon=YES. That's what I was mentioning database.