Re: init scripts problems ?

> So it looks like the slave client has called _exit and is in
> state D, and yet the parent has not been sent sigchild, and the slave
> client is in a semaphore wait somewhere in the kernel. It's dead and
> not dead.

I'm pretty sure that what happens is that the LAST slave client to die
never gets to call the kernel release function (via the close
syscall) and thus the enbd driver never gets to see it.

I think that there may be a "close deadlock" a bit like this ...

    client slave times out and dies, calling _exit()

    (man page: _exit terminates the calling process immediately.  Any
    open file descriptors belonging to the process are closed; any
    children of the process are inherited by process 1, init, and the
    process's parent is sent a SIGCHLD signal)

    The parent does NOT receive a signal, and  the kernel release() 
    function is not called.  Instead, the notionally dead client slave
    is stuck trying to take a semaphore somewhere in kernel.

    I suspect the kernel is flushing something to the device just prior
    to calling release() and it can't because the client daemon is
    responsible for handling such things and it just died. What else
    could it be?
    
It must be some change in kernel semantics in that respect from 2.4.

What I don't get is how come it's only the last slave daemon ... that's
so weird. Maybe I can bump the openers count by one extra on the first
slave open, and decrease it by one more on the last slave close, to fool
the kernel.

Peter