[ENBD] ENBD timeout question...

[Peter T. Breuer]

"A month of sundays ago Daniel Shane wrote:"
> I have one last thing though... When a client shuts down, the nbd-server
> process stays sleeping on the server. When the client reboots, a new

Hmmm ... I think you're talking about the session master. Yes, when the
other end "goes away", the session master can do nothing else except
wait forever for it to come back. Do you want it to die after a certain
time? A repeat count before the select guarding the accept will do the
trick. Or you can  kill -15 (or -9?) it yourself. -9 is probably safer
since I might have got the signal propagation semantics and -15
might propagate back to the master-of-masters server.

> nbd-server gets created and the old one stays there like a dangling
> pointer. 
> 
> Unfortunately, a kill -HUP of the nbd-server process doesnt trigger the

If you're talking about the slave servers,  a kill -9 ought to murder
them. But that'll leave you with the session master restarting a new
one.

> renegotiation timeout, so all the processes basicaly stay in memory and

Well, _a_ process stays in memory, yes :-).

> we have to reboot the server after so many days to remove all the stale
> nbd-server processes.
> 
> Here is the output of a strace on a nbd-server that gets a SIGHUP:

Is sighup meaningful to a server? I forget. Yes, it seems to have
handlers for HUP and INT and TERM. All of the servers seem to have the
same handler, so perhaps it's a case of me not having stratified
the handler code. Mind you .. I see no special action for SIGHUP.
OTOH SIGINT seems to down the network connection, as does SIGTERM.

If you search for "accept(" you will see the accept and the select with
the 5s timeout. It's in the connectme routine. There is a connectme
in main that establishes the ctrl port, and another in negotiate,
presumably for the session port. Can you be more specific about WHICH
server one should get rid of? Grandfather, father or child?


Peter