Ok, that was weird

Last night my linode stopped responding to pings, stopped serving up web pages, stopped accepting ssh connections. I could still get into the host41.linode.com console, but while I could remember the login to the console itself, I couldn't remember my login on my linode. Strangely, while I was there, I kept seeing errors "ssh: xcski.com: Temporary failure in name resolution". xcski.com is the system I was ssh-ing in from, and I checked that I could look up that name from the correct name servers from other sites.

I rebooted my system, and all is well, but I'm wondering if anybody else had any problems with host41 last night, or if it was something died on my linode itself?

12 Replies

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):

[email protected]:~# 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)

[email protected]:~#

[email protected]:~# arp -a

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

[email protected]:~# arp -d 70.85.129.1

[email protected]:~# arp -a

gateway12.linode.com (70.85.129.1) at on eth0

[email protected]:~# 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

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct