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

timeout00

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?

Search Discussions

  • Giovanni Tirloni at Jun 29, 2011 at 2:06 pm

    On Wed, Jun 29, 2011 at 8: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:

    timeout00

    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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos/attachments/20110629/a1bcda9e/attachment.html
  • Ken at Jun 29, 2011 at 3:10 pm

    On 06/29/2011 02:06 PM Giovanni Tirloni wrote:
    On Wed, Jun 29, 2011 at 8:58 AM, ken <gebser at 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:

    timeout00

    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 at Jun 29, 2011 at 3:42 pm

    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
  • Mark Roth at Jun 29, 2011 at 3:45 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.
    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
  • Ken at Jun 29, 2011 at 4:00 pm

    On 06/29/2011 03:45 PM m.roth at 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.
  • Ken at Jun 29, 2011 at 3:54 pm

    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.
  • Ken at Jun 30, 2011 at 11:06 am

    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:

    timeout00

    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?
  • Giovanni Tirloni at Jun 30, 2011 at 11:19 am

    On Thu, Jun 30, 2011 at 12:06 PM, ken 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:

    timeout00

    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

    --
    Giovanni Tirloni
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos/attachments/20110630/97037ac2/attachment.html
  • John Doe at Jun 30, 2011 at 11:21 am
    From: ken <gebser at 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
  • Ken at Jun 30, 2011 at 11:40 am

    On 06/30/2011 11:21 AM John Doe wrote:
    From: ken <gebser at 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-58.el5_6.4.i386.rpm
    --2011-06-30 11:35:44--
    http://ftp.linux.ncsu.edu/pub/CentOS/5.6/updates/i386/RPMS/glibc-common-2.5-58.el5_6.4.i386.rpm
    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 at Jun 30, 2011 at 11:44 am

    On 06/30/2011 11:40 AM ken wrote:
    On 06/30/2011 11:21 AM John Doe wrote:
    From: ken <gebser at 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-58.el5_6.4.i386.rpm
    --2011-06-30 11:35:44--
    http://ftp.linux.ncsu.edu/pub/CentOS/5.6/updates/i386/RPMS/glibc-common-2.5-58.el5_6.4.i386.rpm
    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.
  • Ljubomir Ljubojevic at Jun 30, 2011 at 11:57 am

    ken wrote:
    # wget
    http://ftp.linux.ncsu.edu/pub/CentOS/5.6/updates/i386/RPMS/glibc-common-2.5-58.el5_6.4.i386.rpm
    --2011-06-30 11:35:44--
    http://ftp.linux.ncsu.edu/pub/CentOS/5.6/updates/i386/RPMS/glibc-common-2.5-58.el5_6.4.i386.rpm
    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 at Jun 30, 2011 at 1:15 pm

    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-58.el5_6.4.i386.rpm
    --2011-06-30 11:35:44--
    http://ftp.linux.ncsu.edu/pub/CentOS/5.6/updates/i386/RPMS/glibc-common-2.5-58.el5_6.4.i386.rpm
    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 at 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.

    --
    "When a society comes together and makes decisions in harmony,
    when it respects its most noble traditions, cares for its most
    vulnerable members, treats its forests and lands with respect,
    then it will prosper and not decline."
    --Buddha, Mahaparinirvana Sutra
  • Mark Roth at Jun 30, 2011 at 1:29 pm
    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
  • Ken at Jun 30, 2011 at 1:43 pm

    On 06/30/2011 01:29 PM m.roth at 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. :)

    --
    "When a society comes together and makes decisions in harmony,
    when it respects its most noble traditions, cares for its most
    vulnerable members, treats its forests and lands with respect,
    then it will prosper and not decline."
    --Buddha, Mahaparinirvana Sutra
  • Nicolas Thierry-Mieg at Jun 30, 2011 at 3:07 pm

    m.roth at 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!!)
  • Mark Roth at Jun 30, 2011 at 12:10 pm

    ken wrote:
    On 06/30/2011 11:21 AM John Doe wrote:
    From: ken <gebser at 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
  • Eero Volotinen at Jun 30, 2011 at 12:27 pm
    Reboot your firewall and os?
    30.6.2011 19.11 <m.roth at 5-cent.us> kirjoitti:
    ken wrote:
    On 06/30/2011 11:21 AM John Doe wrote:
    From: ken <gebser at 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 at centos.org
    http://lists.centos.org/mailman/listinfo/centos
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos/attachments/20110630/9be63f51/attachment.html

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedJun 29, '11 at 7:58a
activeJun 30, '11 at 3:07p
posts19
users7
websitecentos.org
irc#centos

People

Translate

site design / logo © 2018 Grokbase