I'm really at my wits end here, so I'm hoping someone here can help me. I have a virtual machine running Ubuntu Server 9.10. It's just a small development environment so I can keep my code separate from the test and production environments. I am running it through VirtualBox 3.1.6 on a laptop running Ubuntu Desktop 9.10. I have it set up with a bridged network connection and it is bridged to my laptop's wireless adapter. We have no wired connections in this office.

I boot up the VM and everything is fine. I can SSH into it using gnome-terminal and for a while everything is Kosher. Then seemingly randomly, the SSH terminal session with hang. No error message, nothing; it just becomes unresponsive. If I go to the VirtualBox terminal I find the VM itself is perfectly fine. It can ping and I can SSH out with it. If I restart the networking on the VM the SSH session in my gnome-terminal will most of the time become responsive again.

Here's an interesting point, the SSH session will sometimes die right in the middle of me typing something (this points to it not being an idle session issue) and if I go to the VirtualBox terminal and restart the networking and then return to my gnome-terminal SSH session I find that it will come back to life and what I typed when the session hung originally will magically type itself in to the buffer. So, my input is getting stored somewhere and just can't make its way to the VM until the networking on the VM is restarted.

I've tried different versions of VirtualBox and used vmdk images and vdi images and nothing seems to work. I can't tell if the problem is with my laptop, VirtualBox, or the Ubuntu Server VDI. Is there anyway to debug this issue? Or has anyone out there seen anything similar?

  • This certainly seems to be network related. I had the VM running under the exact same conditions yesterday on my home wireless network and never once experienced the SSH session hanging. I wonder if it's just due to our wireless infrastructure here at work... – nickbart Apr 9 '10 at 14:26

OK, so I found the root cause of my issue and it's so simple I'm slightly embarrassed: conflicting network IPs. It was indeed a network issue as I had surmised, however, it was not as complicated as I was making it.

Since I am using bridged networking, the VM shows up in the DHCP clients table along with all the other machines on the network. If any one of those other machines grabs my VM's IP from DHCP (say before I boot my VM up for the day) it will cause a conflict whenever my VM comes on line and might cause my VM to stop responding to SSH. This explains why when I was using the VirtualBox terminal, I did not experience any problems at all.

I'm not exactly sure how most routers handle IP conflicts, but it seems that, whichever machine is last to have network activity gets precedence. So when I bounced the networking on my machine it was fine until whichever machine was sharing the IP decided to engage in networking activity and then BOOM ... my connection would hang.

I reset my VM's static network IP to be quite high in our range, so hopefully that will keep it clear of any IP conflicts with my co-workers' machines.

| improve this answer | |
  • I use the same setup and have been noticing the same thing recently. – karlgrz Jun 17 '11 at 15:16

Here is the correct way to keep alive a ssh session

If you own the remote server side then edit the SSH daemon config file

sudo vi /etc/ssh/sshd_config  #  on your server

add these lines

ClientAliveInterval 120 # server sends clients "null packet" every 120 seconds
ClientAliveCountMax 720 # allow clients to stay alive for  720 intervals

720 intervals === (120 seconds * 720 = 86400 seconds = 24 hours)

alternatively if you do NOT own the server side then make this change on your local machine (laptop)

vi  ~/.ssh/config   #  on local host NOT on server

ServerAliveInterval 120
| improve this answer | |

I wasn't aware bridged connections and wireless worked together- least with most VMs i have tried. You'd likely want/need to use nat, or host only and see if you can get that to work

| improve this answer | |
  • The reason I used bridged is because I use a number of shell scripts that have the VM talking to our test environment, so I need it to identify itself on the internal network. This is not possible with NAT, do you know if this is possible with host only? – nickbart Apr 8 '10 at 17:09

Well, I never found the root cause of this issue, but it's definitely something network related. We have a Cisco router here that certainly is a handful some of the time, so the official answer might lie there. I did come up with a work around, however. I wrote a very simple shell script, which I cronned under the root user to run every minute:



/etc/init.d/networking restart
/etc/init.d/ssh restart

This just bounces the networking and Open SSH on the VM server every minute. It's a hacky, inelegant solution, but it keeps my SSH session from permanently hanging. The only reason I find this acceptable, is that it gets the job done and it's only for a small VM server development environment. Naturally, I ABSOLUTELY AM NOT advocating this sort of thing for any kind of production environment.

| improve this answer | |

Are you typing Ctrl+S, which may halt the session (for legacy reasons)? Press Ctrl+Q one of these times its frozen and see whether it un-freezes.

| improve this answer | |
  • No, it's not a BASH thing. It will literally just halt at completely random times. Good idea, though. Interesting follow up though, I have the VM running on my network at home and it has not once had the problem. – nickbart Apr 8 '10 at 18:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.