71

From a Linux SSH shell, type /etc/init.d/network restart to restart the network service.

I expect my SSH connection to die since the network service goes down. But it doesn't. Very cool. But how does Linux achieve this? How does it keep my SSH connection alive across the service restart?

Serge Wautier
  • 918

2 Answers2

79

It does this by doing nothing special. The network restarts in less time than the TCP connection takes to time out, so the TCP connection survives the "outage" the same way it would survive any transient network outage.

The only reason Windows doesn't do the same thing is because Windows specifically resets TCP connections when a network interface goes down. This is, at least arguably, a pretty boneheaded thing to do because TCP was specifically designed to survive transient network outages.

David Schwartz
  • 5,414
  • 1
    David, then it means that the TCP/IP stack is not restarted, right? Because if it were, the server would have lost track of the SSH socket and the sshd child process (thanks Nils) would terminate. Which brings the next question: Which service manages the sockets? TIA. – Serge Wautier Dec 26 '11 at 08:04
  • @David Schwartz - what parameters can I use to change the timeout? How do I find out current timeout value? And is it configured on server side, or client side ? – Martin Vegter Nov 11 '16 at 08:46
  • @MartinVegter You really don't want to change the TCP connection's timing parameters as they have to coordinate on both sides and messing with them could affect TCP's ability to handle packet loss. You're better off designing the system as a whole to tolerate TCP connection loss seamlessly by recovering the connection. – David Schwartz Nov 11 '16 at 16:06
17

SSHD forks a child process on connection. This child process will not die if either SSHD or the whole network is restarted. This is the reason why you can update ssh and/or its configuration, do a service sshd restart and still keep connected to your old ssh-session with the old settings. Apart from that ssh recovers well from small network outages.

Nils
  • 18,492
  • 3
    SSH doesn't even know about 'small network outages', for the reason given by David Schwartz. It's not a property of SSH specifically. – user207421 Dec 26 '11 at 21:40
  • I am not sure if there is not also a little bit of programming involved on the ssh-side. Basically all TCP services should be fault-tolerant - many are not. There needs to be an additional retry mechanism involved in the application - then the service can even survive "medium" outages as well. – Nils Dec 26 '11 at 21:59
  • 3
    As explained by EJP, your answer is true but irrelevant. – Gilles 'SO- stop being evil' Dec 26 '11 at 23:21
  • 5
    This answer was useful to me because it added the insight about what sshd does to avoid going down on service sshd restart. If you update sshd (security update etc), the child processes would still be running on the original code (pre-update), but would continue to provide service, rather than being interrupted. I guess the availability of the listening socket for the main sshd process is very briefly interrupted, however, when the first child process ends and the network interface momentarily indicates the port as closed. – allquixotic Dec 14 '13 at 05:03
  • 1
    @allquixotic This interruption on restart does not matter for already existing connections - they stay connected. The "main" sshd listens then again for NEW incoming requests. Or with other words: upon fork the socket gets personalized as well for a specific connection. – Nils Dec 14 '13 at 22:02
  • @Nils you explain why a ssh session survives a reastart of the ssh daemon. Also a nice feature, but not was was asked. The question was about restarting the network, not restarting the daemon. – Daniel Alder Nov 27 '14 at 11:39
  • 1
    @DanielAlder Read the second sentence of my answer carefully. – Nils Nov 27 '14 at 11:41
  • 1
    @Nils I know that you wrote that. But this makes the average reader thinking that forking is relevant. But the same thing also happens for programs which don't fork. Your answer is something like: "Because steel is stronger than iron, apples are red" – Daniel Alder Nov 27 '14 at 15:07
  • 1
    Well explained, thanks Nils! – silencej Apr 03 '20 at 02:04
  • It is relevant that the sshd process retains the state to do something useful with the TCP connection. It doesn't matter that the OS will keep the socket open if the restarted sshd doesn't know anything about the ongoing connections. The forked sshd child retains that state and is not interrupted by restart of its parent. Of course, there are other ways that sshd could save that state, but it is relevant that forking is how it actually does it. – cmc Dec 18 '20 at 00:57