tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: launchd port: Worth it?

"Aaron B." <> writes:

> On Fri, 15 Mar 2013 11:11:31 -0400
> Greg Troxel <> 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.

Attachment: pgpvgQLHRgLJf.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index