NORMALLY, for SECURITY purposes, operating systems prevent programs from listening on sockets created by other programs. When your program crashes and RESTARTS, the new instance is a different program from the perspective of the operating system. As such it can’t listen on the socket address/port that the previous program was using until after a timeout occurs to make sure the old program was done with it.

The the first step for handling this is to make sure that you provide a method (signal handler, admin WEBSOCKET message, etc) to perform a clean server shutdown.

The clean close strategy won't help in the case of crashes or other abnormal CLOSURES. An option to consider for these cases is the use of the SO_REUSEADDR socket option. That instructs the OS to not request an exclusive lock on the socket. This means that after your program crashes the replacement you start can immediately listen on that address/port combo again.

Normally, for security purposes, operating systems prevent programs from listening on sockets created by other programs. When your program crashes and restarts, the new instance is a different program from the perspective of the operating system. As such it can’t listen on the socket address/port that the previous program was using until after a timeout occurs to make sure the old program was done with it.

The the first step for handling this is to make sure that you provide a method (signal handler, admin websocket message, etc) to perform a clean server shutdown.

The clean close strategy won't help in the case of crashes or other abnormal closures. An option to consider for these cases is the use of the SO_REUSEADDR socket option. That instructs the OS to not request an exclusive lock on the socket. This means that after your program crashes the replacement you start can immediately listen on that address/port combo again.