[ecdavis]

Depends what you mean by server.

Some old game server processes would support a "copyover" function. They would write the file descriptors of connected sockets to a file, restart the process, then read the list of file descriptors back into memory and resume normal use of the socket. Unsophisticated, but it works. It's completely transparent to the client because the connection is never actually closed. The worst the client might experience is some latency as their input gets buffered by the OS while the server process restarts.

Of course the connection would not persist over a physical server restart (or something like a pod being killed or whatever). I imagine it's possible to move a connection between nodes, though, with a fairly similar process.

[rramadass]

>They would write the file descriptors of connected sockets to a file, restart the process, then read the list of file descriptors back into memory and resume normal use of the socket

Nope. When a Process exits for whatever reason, the OS closes and releases all resources connected with all File/Socket descriptors for that Process.

You will have to architect your System to explicitly accommodate this scenario. Some techniques here : https://stackoverflow.com/questions/55006657/can-i-allow-my-...

[twic]

Not quite. Terminating a process releases its filehandles, and if any sockets are now unreferenced, they are closed. But if there is a live filehandle in another process, the socket stays alive.

You can send socket file handles over UNIX domain sockets, so you could use this to export your list of sockets to persist over restart.

[rramadass]

Yep (reference counting in play), It is already mentioned in the SO answer i linked to.

[ecdavis]

Ah, yeah, "restart the process" was not the right description of what was happening in the cases I was thinking of - they'd exec themselves to hot reload code which I see is the first suggestion on the SA answer you linked.