Re: How to automatically add a nbd to a raid1?

"Also sprach Michael Rendell:"
> The fuser is called on the pid file (vs. a device/mount-point), so was
> thinking that maybe enbd-client or enbd-server might keep the pid file
> open when it was running?

Maybe it used to. It doesn't appear to now. As far as I can tell, those
pidfiles are creations of the init script only. So I don't know why it
expected anything to be holding them open. I just removed the fuser
bit. That also made your for loop on the pids it returns not required.

One really should investigate further, however. I'm usually not
completely mad so there might be a reason why that was done. Even a
good one.

I believe the daemons move received signals between them .. at least
from parent to child. So TERM to the parent will kill the child also.
Therefore it suffices to get a signal to the "trunk" of a process tree.
That is why I had no real qualms about removing the for loop .. one
daemon killed should be enough. It does need investigating, though.


More obviously, the interaction between pwprog and the init script needs
considerable thinking about.  At the moment you're disabling pwprog (as
run by mdadm --monitor) while the init script runs.  The init script
effectively runs for quite a while since it starts daemon scripts which
hang around waiting for the other end of a connection to come up before
starting the corresponding daemons.

I'm a little concerned that there may be a multiplicity of waiting init
script slave daemon scripts, and that they may compete for or confuse
the status of the lockout file that lets mdadm start working, or simply
compete with or confuse the pwprog script run by mdadm --monitor.

There's only one pwprog disable file. It will be removed by the init
script running start, which allows pwprog to run thereafter.  It will
be established by the init script running stop, which turns off
the pwprog run from mdadm. The latter is clearly right. Is the start
action right?

If the init script can't start all its daemons at once, that's when it
starts its watchers. Hopefully mdadm won't know about the missing enbd
devices at this point, so it won't ever tell pwprog to try and recover
enbd devices (which don't yet exist) into raid arrays. That saves
pwprog from competing with the init script. But it leaves a hole ..
the init script watchers will start the enbd connections. Then nothing
.. mdadm won't act. One needs to use the udev notice or the init script
itself to put the new enbd devices into raid arrays. After that one can
leave everything to pwprog.

So I don't see there's anything wrong with your approach.  Nevertheless,
I feel bad about something ..  it seems to me that there ought to be one
lockout file for pwprog per enbd device, not one lockout file full stop.
But I don't know why I feel that.  Perhaps it'll come to me ..  tomorrow
I have to be on a train.

Oh .. that shell was extemely well written. Well done. But I expect you
know that! One can't write that well without recognizing it :).

Thanks

Peter