On 06/29/2011 02:06 PM Giovanni Tirloni wrote:

On Wed, Jun 29, 2011 at 8:58 AM, ken <gebser@mousecar.com mailto:gebser@mousecar.com> wrote:

Trying to update a second CentOS box, I'm getting this error repeatedly:

[Errno 4] Socket Error: timed out

I'm getting this on every mirror and have gone through the list of
mirrors more than a dozen times.

Oddly, the RPMs I'm trying to upgrade I upgraded just yesterday without
a problem on another machine on the same LAN with no problems
whatsoever.  I can ping mirrors fine.

There were a spate of these errors back in 2006.  The fix for many was
to add this line to yum.conf:

timeout=300

So I did that on the machine where yum is having the problem, but the
same errors are returned.

I would start by trying to telnet to port 80 on these mirrors, see if it can establish a connection, if not, who's blocking it, iptables, etc.

-- Giovanni Tirloni

Giovanni,

Good thought. But that machine can reach port 80 on the mirrors... nothing blocking it.

So it would appear that the problem is with yum itself... as installed on the problem machine. But it's been working fine for years and there's been no changes to yum.conf.

I've upped the debug level (to 4). I'll run that awhile and see what I get.

Thanks again.

Ljubomir Ljubojevic wrote:

ken wrote:

...

Good thought. But that machine can reach port 80 on the mirrors... nothing blocking it.

So it would appear that the problem is with yum itself... as installed on the problem machine. But it's been working fine for years and there's been no changes to yum.conf.

I've upped the debug level (to 4). I'll run that awhile and see what I get.

Is it possible you have DNS errors on that machine?

Or could permissions on a directory have accidentally been changed, and it can't create the socket?

Nooo, I just looked at errno.h, and that says corrupt shared library.

mark

On 06/29/2011 03:42 PM Ljubomir Ljubojevic wrote:

ken wrote:

...

Good thought. But that machine can reach port 80 on the mirrors... nothing blocking it.

So it would appear that the problem is with yum itself... as installed on the problem machine. But it's been working fine for years and there's been no changes to yum.conf.

I've upped the debug level (to 4). I'll run that awhile and see what I get.

Thanks again.

Is it possible you have DNS errors on that machine?

Ljubomir

That would be a possibility, but I'm able to both ping and telnet:80 from the problem box to the mirrors. Due to the structure of the IP stack, a DNS error would have shown up with those other commands.

On Thu, Jun 30, 2011 at 12:06 PM, ken gebser@mousecar.com wrote:

On 06/29/2011 07:58 AM ken wrote:

...

Trying to update a second CentOS box, I'm getting this error repeatedly:

[Errno 4] Socket Error: timed out

I'm getting this on every mirror and have gone through the list of mirrors more than a dozen times.

Oddly, the RPMs I'm trying to upgrade I upgraded just yesterday without a problem on another machine on the same LAN with no problems whatsoever. I can ping mirrors fine.

There were a spate of these errors back in 2006. The fix for many was to add this line to yum.conf:

timeout=300

So I did that on the machine where yum is having the problem, but the same errors are returned.

Anyone else seeing this? Anyone know what the problem is?

So I tried using wget to download RPMs from a few mirrors. I was able to successfully one whose size is about 5.5M, but the others all stop downloading around 1M. Then I tried ftp... same deal. This might be the reason for the "socket error" in yum.

I don't have quotas set on this machine. selinux is on, but it's been on for years... why should it start interfering now? I'm downloading into /tmp where security settings are standard (user_u:object_r:tmp_t).

Fire up tcpdump/wireshark and record the TCP connection then analyze it with Wireshark and you can check for retransmissions, etc.

A while ago I had to add the following to my Fedora 13/14 system to download from some sites.

/etc/sysctl.conf: net.ipv4.tcp_timestamps = 0

On 06/30/2011 11:21 AM John Doe wrote:

From: ken gebser@mousecar.com

...

So I tried using wget to download RPMs from a few mirrors. I was able to successfully one whose size is about 5.5M, but the others all stop downloading around 1M. Then I tried ftp... same deal. This might be the reason for the "socket error" in yum.

When you say "stop downloading", what do you mean? Clean stop? Network error message? Filesystem? Maybe you could try to wget to /dev/null and see if it goes further? Or try to strace a wget to see what happens...

JD

Sorry, I should have been clearer. What happens is that the download simply hangs. Doing ftp I turn on the 'hash' option so the ftp server prints a # for every 1k (or something?). It'll print a half a screen full of #s then stop; and I won't get the "ftp>" prompt back, even should I wait a half hour for it.

Using wget it's pretty much the same idea. On the left of the display it'll show something like this:

------------------------------------------------------- # wget http://ftp.linux.ncsu.edu/pub/CentOS/5.6/updates/i386/RPMS/glibc-common-2.5-... --2011-06-30 11:35:44-- http://ftp.linux.ncsu.edu/pub/CentOS/5.6/updates/i386/RPMS/glibc-common-2.5-... Resolving ftp.linux.ncsu.edu... 152.1.2.172 Connecting to ftp.linux.ncsu.edu|152.1.2.172|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 17244521 (16M) [application/octet-stream] Saving to: `glibc-common-2.5-58.el5_6.4.i386.rpm'

5% [=> ] 1,029,216 --.-K/s eta 23m 10s -------------------------------------------------------

and just freeze there... except the right two numbers (following "eta") will continue to climb higher... it stays at "5%" and "1,029,216" doesn't change, and there's no activity between those two numbers. In short, the download just stops or freezes.

ken wrote:

# wget http://ftp.linux.ncsu.edu/pub/CentOS/5.6/updates/i386/RPMS/glibc-common-2.5-... --2011-06-30 11:35:44-- http://ftp.linux.ncsu.edu/pub/CentOS/5.6/updates/i386/RPMS/glibc-common-2.5-... Resolving ftp.linux.ncsu.edu... 152.1.2.172 Connecting to ftp.linux.ncsu.edu|152.1.2.172|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 17244521 (16M) [application/octet-stream] Saving to: `glibc-common-2.5-58.el5_6.4.i386.rpm'

5% [=> ] 1,029,216 --.-K/s eta 23m 10s

and just freeze there... except the right two numbers (following "eta") will continue to climb higher... it stays at "5%" and "1,029,216" doesn't change, and there's no activity between those two numbers. In short, the download just stops or freezes.

Have you checked your network interface on your network connection in general? First try the same PC in different network environment (home, another location?) and then try to setup another PC with the same IP in the same network environment as original PC.

Ljubomir

ken wrote: <snip>

So, shifting into work-around mode... I used wget to download glibc-common (the troublesome file) to another machine. No problem. Then I scp'd it to the problem machine-- again no problem-- and successfully installed it there using rpm.

A strong recommendation: rpm -e, then yum localinstall. That way, yum's d/b will be correct.

mark

m.roth@5-cent.us wrote:

ken wrote:

<snip> > So, shifting into work-around mode... I used wget to download > glibc-common (the troublesome file) to another machine. No problem. > Then I scp'd it to the problem machine-- again no problem-- and > successfully installed it there using rpm.

A strong recommendation: rpm -e, then yum localinstall. That way, yum's d/b will be correct.

yum doesn't have a db of installed packages, it relies on rpm for that. (fortunately!!)

Reboot your firewall and os? 30.6.2011 19.11 m.roth@5-cent.us kirjoitti:

ken wrote:

...

On 06/30/2011 11:21 AM John Doe wrote:

...

From: ken gebser@mousecar.com

...

So I tried using wget to download RPMs from a few mirrors. I was able to successfully one whose size is about 5.5M, but the others all stop downloading around 1M. Then I tried ftp... same deal. This might be the reason for the "socket error" in yum.

When you say "stop downloading", what do you mean? Clean stop? Network error message? Filesystem? Maybe you could try to wget to /dev/null and see if it goes further? Or try to strace a wget to see what happens...

Sorry, I should have been clearer. What happens is that the download simply hangs. Doing ftp I turn on the 'hash' option so the ftp server prints a # for every 1k (or something?). It'll print a half a screen full of #s then stop; and I won't get the "ftp>" prompt back, even should I wait a half hour for it.

Using wget it's pretty much the same idea. On the left of the display it'll show something like this:

<snip> > and just freeze there... except the right two numbers (following "eta") > will continue to climb higher... it stays at "5%" and "1,029,216" > doesn't change, and there's no activity between those two numbers. In > short, the download just stops or freezes.

Consider attaching strace, and see what it's waiting for?

mark

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos