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

On Wednesday 17 December 2008 18:05, Peter Breuer wrote:
... (udev events) ...
> You're right.  2.4.35 doesn't have the UDEV messages in.
> You'll need the bit from 2.4.35a that has that in.
>
> This supports talking to udev about connection or disconnection, using
> kobjs.
(patch)

Thanks for the patches - will try them out!



...
> > Patches for pwprog:
...
> >     - when writing lock files, write the running process's PID
> >       to the lock file and not "$$" ($$ after a "&" is not the
> >       currently running process PID - it is the original process PID).
>
> But that's right, isn't it? The only call to "lock" (which does the
> write) that I can see is in the fail_action(), which launches a daemon
> to wait for the failed server to come back online. It IS the parent
> which does the lock. The launched daemon just sits around grumpily
> doing pings every so often.
>
> OK, the launched daemon runs an unlock when it dies, which requires
> reading a lock from the lock file and comparing it with $$, which
> IS that of its parent. So I don't see the problem.
>
> Also the parent won't be able to launch a second daemon, since
> the lockfile is already heald by a live process (whose pid is recorded
> in it) - itself. That's correct too.

The problem is that the parent launches the daemon and then the parent
exits - its pid is in the lock file and it is dead, but the daemon is
still running.   So if the program (pwprog) is run again, it will
think the lock file is invalid and start a second daemon.

The situation with the init script is similar, only multiple daemons
may be started, but as the lock file is unique per client/server/disk,
the same logic holds (the parent starts the daemons and exits, daemon
lives, etc.).


> >     - update the pid in the lock file after a "&"
>
> That's not necessary, by the argument I just gave. I see .. you want to
> have the child daeon's pid in the pidfile instead of the parent's! But
> no .. that won't really work .. it leaves one open to multiple launches
> from the same parent. Better to have the parent's pid in there.

For both pwprog and the init script, the parent will check the lock
and find it locked (if the daemon is still running), which is the right
thing.


> >       also, use a single kill of $pid and fuser output instead
> >       (not sure what the purpose of the fuser kill was, so this
>
> Presumably I would have wanted to kill processes running
> mounted on the device in order to remove openers and allow many things
> to disappear.


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?

Thanks again!

Best wishes,
Michael