Re: init scripts problems ?

"Also sprach denis bonnenfant:"
> But now, thanks to a power outage with UPS batteries dead, i notice a 
> potential problem with init scripts :

OK - you mean init.d/enbd?

> I'm exporting two enbd device on the server, and it seems that enbd init 
> script is doing something wrong when restarting enbd link  :
> 
> Sounds like a race condition between enbd script and 
> enbd-sstatd/enbd-cstatd daemons, causing enbd-client to be lauched twice 

This is feasible. Starting the SERVER will tell the enbd-cstatd to
restart/reconnect the CLIENT if there was no formal divorce. 

I suspect the easiest thing to do is wipe the /var/blah/nbd directory
where the server keeps lists of old clients (and v.v.).

> nearly at the same time, leaving enbd in an undefined state, nearly 
> impossible to recover, except with reboot:(

??  Hmm.  Well, I'm not sure that starting the client twice would be a
problem, would it? the last one to start should kill the earlier one,
I'm pretty sure. But I agree there is a potential problem.

> the same problem occurs when i start the 2 clients simutlaneously with 
> init script

I'm not sure of the problem. The more you can find out the better.


> If i start server A first, then client A, wait 30 sec, then start server 
> B, client B, everything goes fine.
> 
> So there are two potential points :
> 
> - simultaneous start/stop of different clients

This is always difficult - there are few good solutions (don't do that
then :-). As far as I recall, connecting a second enbd client KILLS the
first client, so I would be interested to  hear about why not, if not.

> - protection of enbd init script from automatic sstatd/cstatd connexion

I'm not sure it needs protection, but clearly there is a conceptual
design waiting to be clarified here!

> I looked a little bit at enbd init script again, and some code seems to 
> be redundant or interfered with the sstatd/cstatd mechanism. So, can i 
> rely on this script, or it is preferable to use directy enbd-client and 
> enbd-server in my redundancy scripts ?

We'll have to investigate the problem exactly first. Can you find out
what is _exactly_ wrong with starting two clients near the same time?
What they are doing, I mean?

> The other point we discuss later was the ability of saving fr1 bitmap 
> from user-space when stopping the array, allowing fast reconstruction to 
> be relocated on another node. Have you any new ideas about that (like a 
> /proc/fr1 file for example)  ?

Well, that would be potentially very big - but it's not impossible.
It's just that proc files are not really meant to be big, and the
mechanism is not fantastic - it might be susceptible to subtle "off by
one errors" but I might try this. I have had no time as I have had to
write three papers and a ministry report (as well as apply for jobs,
and do some of my own :-).

I could try that proc thing. It may not work, but maybe I can get clse
enough. Hmm.


Peter