"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.
Attachment:
pgpvgQLHRgLJf.pgp
Description: PGP signature