Ok, that was weird

I had the same thing on linode51. A reboot fixed it.

There were other people in IRC with the same problem, and taking the eht0 interface down and bringing it back up also fixed it.

I guess we'll get an explanation when daylight breaks in Texas or Florida :-)

Had the same problem on host32 this morning at 9:25 GMT. From the Linode I couldn't even ping the default gateway, though there were no messages in syslog etc.

In the end I rebooted it so I'd get the upgrade to 80M of RAM, but I did wonder if bouncing the ethernet interface would fix it.

It's a bit worrying that this seems to have affected different hosts with the same problem. I hope Caker can get to the bottom of this.

Same thing for me, although I found that issuing

/etc/init.d/networking restart

fixed everything.

Me too, host33. No connectivity from the outside at 9:25 EST. No messages in syslog. Brought down eth0 and then brought it up using /etc/rc.d/rc.inet1 (Slackware). Now all is well.

It appears the problem started for me around 1:00am EST. Here's what netstat had to say while the system was wedged (an unusual preponderance of SYN_RECV and no other non-LISTEN states):

root@linode:~# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:110             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 70.85.16.41:80          137.203.140.95:1371     SYN_RECV
tcp        0      0 70.85.16.41:80          137.203.140.95:1373     SYN_RECV
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN
tcp        0      0 70.85.16.41:22          137.203.143.138:3318    SYN_RECV
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
tcp        0      0 70.85.16.41:25          209.79.220.26:47299     SYN_RECV
tcp        0      0 70.85.16.41:25          195.121.6.174:28183     SYN_RECV
tcp        0      0 70.85.16.41:25          81.228.11.98:40643      SYN_RECV
tcp        0      0 70.85.16.41:25          200.221.4.129:45199     SYN_RECV
tcp        0      0 70.85.16.41:25          195.110.126.63:2362     SYN_RECV
tcp        0      0 70.85.16.41:25          213.134.38.68:13845     SYN_RECV
tcp        0      0 70.85.16.41:25          195.6.202.253:41413     SYN_RECV
tcp        0      0 70.85.16.41:25          194.83.112.9:34206      SYN_RECV
tcp        0      0 70.85.16.41:25          207.115.20.47:57167     SYN_RECV
tcp        0      0 70.85.16.41:25          193.109.255.35:54714    SYN_RECV
tcp        0      0 70.85.16.41:25          66.118.64.16:46311      SYN_RECV
tcp        0      0 70.85.16.41:25          62.79.79.29:58677       SYN_RECV
tcp        0      0 70.85.16.41:25          149.155.202.2:35862     SYN_RECV
tcp        0      0 70.85.16.41:25          195.6.202.218:41413     SYN_RECV
tcp        0      0 70.85.16.41:25          206.131.246.136:36753   SYN_RECV
tcp        0      0 70.85.16.41:25          203.12.160.101:36642    SYN_RECV
tcp        0      0 70.85.16.41:25          71.36.29.90:4281        SYN_RECV
tcp        0      0 70.85.16.41:25          195.188.213.9:27615     SYN_RECV
tcp        0      0 :::22                   :::*                    LISTEN
udp     1700      0 0.0.0.0:68              0.0.0.0:*

Me too, host45

"/etc/init.d/networking restart" command on Debian from lish fixed it.

Went down around 1030 GMT

@drware:

"/etc/init.d/networking restart" command on Debian from lish fixed it.
If you're using Gentoo, as I am, this is the command to use:

/etc/init.d/net.eth0 restart

BTW: My problem started at about 5:35am EST.

I can confirm that I experienced the problem on host52 starting at 4:25am EST. I'm running a recent installation of Gentoo.

The MAC address appears to have changed on the gateway.

(This is from host45)

root@overbeck:~#

root@overbeck:~# arp -a

? (70.85.129.1) at 00:00:0C:07:AC:07 [ether] on eth0

root@overbeck:~# arp -d 70.85.129.1

root@overbeck:~# arp -a

gateway12.linode.com (70.85.129.1) at on eth0

root@overbeck:~# arp -a

gateway12.linode.com (70.85.129.1) at 00:00:0C:07:AC:01 [ether] on eth0

Simple fix: flush the arp table entry for your gateway. (you don't have to cycle the interface, just fix the arp table.)

Interesting; shouldn't the value automatically expire after a period of time? Is this a UML-specific problem somehow?

I had the same thing happen around 4 am EST.

It fixed itself after about 10 min.

• Robbert