What happens to lingering sockets when the kernel reboots?

Question

I'm trying to understand what the typical behavior for the following scenario. Please note I'm open to finding out more about this edge case for any OS (*nix, Windows, ...).

If an application is blocked waiting or a lingering socket to close, what happens when the machine is rebooted?

Consider the following example scenario:

1. An application has an established TCP socket, and then calls close() on the socket. The socket is configured to linger (SO_LINGER) for say, 10 seconds.

2. Due to the linger setting, the application blocks, waiting for (up to) the 10 second linger time to TX/RX/ACK remaining data on the connection.

3. During this time, the kernel is rebooted (e.g. user reboots the machine).

What does the kernel do in such a case?

Does it force the socket to close ("abortive close")? Causing any unsent/un-ACK'd data to be lost?

Or does it respect the linger time and wait for the (possibly) full 10 seconds? (Thus blocking the reboot, possibly until the full 10 second linger time has expired).

Something else?

Thanks,

Steve

Answer 1

My answer is for Linux, although I imagine Windows services are the same.

It depends on how the machine is rebooted. If it goes through the normal shutdown process, the TCP sockets will act the same as they do if the application is shut down normally. Because that is what happens.

If the application does not shut down within the init system's timeout, it will be killed with SIGKILL and simply stop running. Data already written to the socket's kernel buffer will be sent as if SO_LINGER was not set. Anything that wasn't buffered is lost.

Once the init system gets done it will actually reboot the machine with the reboot system call. See man 2 reboot. This immediately reboots the machine. It does not even wait for a disk sync. It certainly won't wait for TCP sockets. You can get this effect from the command line with reboot -n -f. Any data in the kernel's TCP socket buffers is lost.