Re: depend take 2

[Rory Toma]

It's a tough problem to do cleanly. Once you're done, I'm going to see
if I can eliminate some redundant code and clean up a bit, there are
some things about the new code I like better.

I think the main thing that I'd like to see changed is to have all
processes when they are going to be stopped/started go thru a single
piece of logic.

Hey, I just had a thought. We could change to a 2-pass parse when we
parse monitrc. The first pass could be on the "check" line, and we
create all the process entries. The second pass fills in the fields, and
at that time, p->dependant and p->parent can be filled in. This might
make things easier.


> 
> If you remember the depend matrix gif I sent in a previous mail this
> code tries to travers (isn't it called that in english?) or follow a
> depend path in the matrix and mark elements as they are visited and
> started/stopped in real time. In the old code all processes was not
> started in real time (the same cycle) but waited for the next monit
> cycle to pick them up for start.

This isn't neccessarily true. Here's what would happen:

We enter check_process (by either validate or other)

Mark do_validate flag (if neccessary)

if action is start, check status of parent, punt if parent isn't running

stop dependant processes (with each going thru check_process above)

start/stop process

if start, start dependant processes (again, going thru control_process)

the visited flag only gets set after spawn.

So, in the case of slow-starting processes, we could skip a cycle.


Actually, not that I think about it, I could make the following mods to
my old code that would probably work.

Currently, when we decide we want to start/stop something, we call
atomic_control_process. I could change this to a different function,
that replaces spawn() with a call that adds the process name and action
to a linked list. So, in the case above, we'd have a list that says:

gpm:stop
xinetd:stop
sshd:stop
sshd:start
xinetd:start
gpm:start

We then pass this list to a loop like:

for (p=actionlist; p; p->next)
        spawn(p, p->action);

I think this splits the difference nicely.
> 
> On the other hand since I misunderstod how the depend worked in the
> old code I'm not 100% certain. 
> 
> Anyway I see now that the new code also suffers from in what order the
> entries are written in the monitrc file, but I'm fixing this now to
> order the processlist in a depending order. Keep the old code and
> maybe we can revert back (if it works as you said with the
> modifications you mentioned) but include the loop check and the new
> depend order functions I'm adding now.

The beauty of CVS, it's still there. 8-)

-- 
Rory Toma               address@hidden
VP of Run Level 5       http://www.trs80.net
Digeo Digital           http://www.digeo.com

signature.asc
Description: This is a digitally signed message part