Re: init scripts problems ?

"Also sprach Peter T. Breuer:"
> You claim that just _starting_ two clients for two servers at the same
> time, there is a problem - that may be so. I think I am more concerned
> however that you say can also get stuck sometimes with just ONE client start.

Let me state the problem that I sort of know about - a client finds it
hard to die.

If I setup a client-server link and then later start a second instance
of the client, this should replace the first instance. It does so by
contacting the server, which kills its server slave, and starts
another. The original client, talking to the dead server, will timeout
and die in about three repetitions  of a 30s timeout.

That's the theory, and that actually HAPPENS. I watched it on a strace:

   write(2, "enbd-client 11552: # 156 unplug:"..., 105enbd-client
   11552: # 156 unplug: requested unplug (0) Invalid argument on localhost:3035 so clear socket) = 105
   getpid()                                = 11552
   ioctl(4, 0x4004ab04, 0x2d20)            = -1 EINVAL (Invalid argument)
   time([1133676961])                      = 1133676961
   rt_sigaction(SIGPIPE, {0x400ca05c, [], 0x4000000}, {SIG_DFL}, 8) = 0
   send(3, "<62>Dec  4 07:16:01 enbd-client:"..., 86, 0) = 86
   rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
   getpid()                                = 11552
   write(2, "enbd-client 11552:", 18enbd-client 11552:)      = 18
   write(2, " client (0) last error Invalid a"..., 40 client (0) last error Invalid argument = 40
   _exit(0)                                = ?

Bye bye. Except NOW it's stuck in a semaphore somewhere. This is what
ps axl shows:

   144     0 11552 11544  16   0     0    0 down   DW   ?          0:01 [enbd-client]

Now - that was userland code that died happy, and yet the kernel is
holding on to it.  Why? Is it trying to send sigchld to its parent?
pstree shows:

           |-enbd-client(11544)---enbd-client(11552)
                                  ^^^^^^^^^^^^^^^^^^^ old dead
           |-enbd-client(11662)---enbd-client(11667)

Its parent appears to be calling schedule().

   140     0 11544     1  15   0  1568  932 schedu S    ?          0:00 /tmp/enbd-client localhost 3033 -n 1 /dev/nda

So it is live. A strace shows that it is in the service loop at the end of
main() happily sending ioctl MY_NBD_SYNC to the device. It should be
capable of receiving sigchld and handling it! But it hasn't received
sigchld - the code shows that it would have yelled if it had.

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.

What semaphore is it? That's what I don't know. Is it mine? Is it the
kernels?

Sending 0 to nbdinfo clears the situation and allows everything to
proceed normally.

Peter