Steps:
First:
After receiving Sigterm, now the server listens for socket stop accept
But it doesn't stop listen, which is key. (so the SYN of the client-initiated TCP connection is not synack, just keep waiting and not be rejected )
?
Second:
The existing process receiving sigterm continues to handle the socket that has been received.
Exit until the end of processing is complete.
Third:
After receiving Sigterm, send sighup (to ensure that the existing server process has stopped the accept).
Fourth:
After receiving sighup the existing server process SERVERID1, to fork a new process,
Then pass the listen socket handle to the new exec created server process SERVERID2 (as for how to pass, self-Baidu)
At the same time, through the environment variables and other mechanisms to tell the newly created SERVERID2, you do not have to create a new socket listen, directly with my pass to your handle on the line.
SERVERID2 directly with this handle happy accept on the line.
This way the new server process is fully operational.
?
This thing under win No, I think it may be because of the following two reasons
EXE runtime can not be covered, in fact, I think matter, with a different name on it.
Handle descriptors cannot be passed across processes?
?
This is a time to look into it.
Say the *nix I know. Server Hot restart