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?
On Wed, Jun 29, 2011 at 8:58 AM, ken 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.
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.
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
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:45 PM m.roth@5-cent.us wrote:
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
Yeah, the making of a socket shouldn't at all depend upon the permissions on a directory where a file is to be saved... it's possible and happens often that a socket is set up and no data is saved/written locally. But then it's possible that the yum code is saying it's a socket error when it's actually some other kind of error. We'd have to examine the source code to ascertain that... and probably while the code is running in order to find where in the code the error's being kicked out. That's a bit more than I want to get into today.
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 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).
Any ideas?
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
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
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.
On 06/30/2011 11:40 AM 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...
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.
One more thing: To exit from the wget above, I have to do a Ctrl-C. Then I get this error code:
# echo $? 130
It might just mean "user hit Ctrl-C", I don't know, haven't tried to look it up yet.
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
On 06/30/2011 11:57 AM Ljubomir Ljubojevic wrote:
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 _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
In the last half hour I successfully used yum to download and install strace, krb5-workstation and krb5-libs... for this and other reasons I'm pretty sure I don't have a network problem. yum and wget and ftp all seem to have a problem downloading glibc-common-2.5-58.el5_6.4.i386.rpm... perhaps because it's rather large (16M), or simply larger than 1M. But then I was able to ftp one file which was 5M.
Ljubomir, you are correct in that it's some kind of network problem-- well, it could have something to do with limits or some extra-weird permissions thing I don't know about. You'll see I've amended the Subject line to indicate it's probably a network problem.
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.
Now that everything's been upgraded, the urgency has gone out of the situation. I had thought to use strace and/or tcpdump as was suggested (thanks for those suggestions), but I've found those utilities give a lot of output and take a lot of time to analyze (for me anyway). With other things I need to get to today, I'll be saving those small projects for another day.
But just one other quick test: I used scp on the problem box to download that same glibc-common rpm file from the local machine (residing on the same LAN and in the same network block) mentioned above. It worked fine, even downloading to the same directory (/tmp). And, yes, rpm verified that the file was complete and uncorrupted. This narrows the problem down to a couple pockets.
If I find anything more, I'll post back.
Thanks for all the suggestions, everyone.
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
On 06/30/2011 01:29 PM 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.
mark
It's not necessary. When I do "yum update" now (after having installed five packages using rpm), yum confirms "No packages marked for Update".
...which is nice. :)
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!!)
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
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
-
Eero Volotinen -
Giovanni Tirloni -
John Doe -
ken -
Ljubomir Ljubojevic -
m.roth＠5-cent.us -
Nicolas Thierry-Mieg