CODEWITHSUNDEEP
google-compute-engine
teteArg
teteArg

Reputation: 4014

ssh connection time out after reboot GCE instance

Can anyone tell me why after reboot a Google Compute Engine instance i get a ssh connection time out. I reboot the instance by sudo reboot and by Google Compute Engine Console and both do the same.

Upvotes: 3

Views: 1910

Answers (5)

vgt
vgt

Reputation: 217

Slightly orthogonal to Brian's answer. To gracefully reboot a GCE VM you can use:

gcutil resetinstance <instancename>

Upvotes: 0

Nan Hui
Nan Hui

Reputation: 31

If your instance image is CentOS, try to remove selinux.

sudo yum remove selinux*

Upvotes: 0

teteArg
teteArg

Reputation: 4014

Thank you Brian Dorsey, E. Anderson and vgt for answering my question. The problem was other. Every time that i reseted the connection previously i up an ethernet bridge with the brigde-util utility between the "eth0" inferface and a new brigde interface called "br0". After reset the instance by sudo reboot or by GCE Console, ssh connection stopped working.

But if i don't up the ethernet bridge the instance restart ok by both methods.

Upvotes: 2

E. Anderson
E. Anderson

Reputation: 3493

When you use gcutil resetinstance, it does the same thing as pushing the power button on a physical host. This is different from e.g. sudo reboot, because the former does not give the operating system a chance to perform any shutdown (like closing open sockets, flushing buffers, etc), while the latter does an orderly shutdown.

You should probably prefer logging in to the instance to do a reboot rather than using gcutil resetinstance if the host is still ssh-able; resetinstance (or the "Reboot Instance" button in the GUI) is a hard reset, which allows you to recover from a kernel crash or SSH failing.

In more detail:

During OS-initiated reboot (like sudo reboot), the operating system performs a number of cleanup steps and then moves to runlevel 6 (reboot). This causes all the scripts in /etc/init.d to be run and then a graceful shutdown. During a graceful shutdown, sshd will be killed; sshd could catch the kill signal to close all of its open sockets. Closing the socket will cause a FIN TCP packet to be sent, starting an orderly TCP teardown ("Connection closed" message in your ssh client). Alternatively, if sshd simply exits, the kernel sends a RST (reset) packet on all open TCP sockets, which will cause a "Connection reset" message on your ssh client. Once all the processes have been shut down, the kernel will make sure that all dirty pages in the page cache are flushed to disk, then execute one of two or three mechanisms to trigger a BIOS reboot. (ACPI, keyboard controller, or triple-fault.)

When triggering an external reset (e.g. via the resetinstance API call or GUI), the VM will go immediately to the last step, and the operating system won't have a chance to do any of the graceful shutdown steps above. This means your ssh client won't receive a FIN or RST packet like above, and will only notice the connection closed when the remote server stops responding. ("Connection timed out")

Upvotes: 2

Brian Dorsey
Brian Dorsey

Reputation: 4688

When the OS shuts down to reboot, all network connections are closed, including SSH connections. From the client side, this can look like a connection time out.

Upvotes: 5

Related Questions