Re: [Nbd] Restart without killing clients
> On 6 Oct 2016, at 13:43, Wouter Verhelst <w@...112...> wrote:
>
> One major limitation which nbd-server currently has is that you can't
> restart it without killing all existing connections. This isn't ideal.
> The reason I wrote it that way is that when you shut down the server,
> it should really stop all processes.
>
> However, recently I've become more and more convinced that in the case
> of nbd, this doesn't really make much sense. Sure, when a webserver
> restarts, it doesn't hurt to restart the forked off processes of that
> webserver, since they're all serving short-lived TCP connections anyway.
> However, the same is simply not true for nbd; we serve long-lived TCP
> connections, and killing the child processes of the master nbd-server
> impacts clients.
>
> I think it's time I thought about a way to restart the server without
> impacting existing clients. Since nbd uses a fork-per-client method,
> this shouldn't be too hard (just stop proxying signals from the master
> process to its child processes, instead just shutdown the master process
> and be done with it). However, it might be interesting to allow clients
> to remain running when restarting the server, but not when shutting it
> down, even if the server had been restarted at some prior point. I guess
> this should be possible using some IPC method, but I'm not sure whether
> the extra complexity required for that is worth it.
It would be useful to understand more what you need to do.
gonbdserver can reread its configuration transparently.
As I understand it, the kernel and nbd-client are now meant to
reeastablish the TCP session if it is interrupted. I have no idea how
well this actually works in practice. If it does work in practice,
then one can ALMOST do this simply by terminating the listen(),
using shutdown(fd, SHUT_RD) on the socket, and processing and replying
to everything that comes through, then shutdown(fd, SHUT_RDWR) and
finally closing the socket. I'd be worried about commands stuck in the
TCP queue client side, but it might be just as easy to fix that there.
I'm guessing that you're looking for something cleaner involving
some slightly more complicated signalling?
--
Alex Bligh
Reply to: