Why does yum update fail in CentOS 6.4?

Question

I am using CentOS 6.4 in a corporate lab, and the yum update fails with the below error:

I am able to access the same repositories through the browser.

[root@LAB1 ~]# yum update
Loaded plugins: refresh-packagekit, security
base                                                     | 3.7 kB     00:00     
http://centosmirror.go4hosting.in/centos/6.4/os/x86_64/repodata/1e584feac3f3fb76ad4b6fb7e1bc8d44fa124814e9d186dc913ded3c63a216b3-primary.sqlite.bz2: [Errno 12] Timeout on http://centosmirror.go4hosting.in/centos/6.4/os/x86_64/repodata/1e584feac3f3fb76ad4b6fb7e1bc8d44fa124814e9d186dc913ded3c63a216b3-primary.sqlite.bz2: (28, 'Operation too slow. Less than 1 bytes/sec transfered the last 30 seconds')
Trying other mirror.  
.  
.  
.  
Error: failure: repodata/1e584feac3f3fb76ad4b6fb7e1bc8d44fa124814e9d186dc913ded3c63a216b3-primary.sqlite.bz2 from base: [Errno 256] No more mirrors to try.

Below is what I have in /etc/yum.repos.d/CentOS-Base.repo

[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

#released updates
[updates]
name=CentOS-$releasever - Updates

Here is what I have in /etc/resolv.conf

# Generated by NetworkManager
search xxx.xxx
nameserver 192.168.1.3

yum.conf file:

[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=5
bugtracker_url=http://bugs.centos.org/set_project.php?project_id=16&ref=http://bugs.centos.org/bug_report_page.php?category=yum
distroverpkg=centos-release
http_caching=packages

I am able to ping the above nameserver. And I have tried the yum update after running yum clean all but with the same result.

I am able to wget/curl the same link and it connects and downloads. I also tried yum update right after, which again failed with the same error. Here is the output:

[root@LAB1 ~]# wget http://centosmirror.go4hosting.in/centos/6.4/os/x86_64/repodata/1e584feac3f3fb76ad4b6fb7e1bc8d44fa124814e9d186dc913ded3c63a216b3-primary.sqlite.bz2
--2013-11-15 21:29:45--  http://centosmirror.go4hosting.in/centos/6.4/os/x86_64/repodata/1e584feac3f3fb76ad4b6fb7e1bc8d44fa124814e9d186dc913ded3c63a216b3-primary.sqlite.bz2
Connecting to centosmirror.go4hosting.in|111.118.183.138|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4578998 (4.4M) [application/x-bzip2]
Saving to: “1e584feac3f3fb76ad4b6fb7e1bc8d44fa124814e9d186dc913ded3c63a216b3-primary.sqlite.bz2”

100%[======================================>] 4,578,998   5.52M/s   in 0.8s    

2013-11-15 21:30:50 (5.52 MB/s) - “1e584feac3f3fb76ad4b6fb7e1bc8d44fa124814e9d186dc913ded3c63a216b3-primary.sqlite.bz2” saved [4578998/4578998]

FINISHED --2013-11-15 21:30:50--
Downloaded: 1 files, 4.4M in 0.8s (5.52 MB/s)

[root@LAB1 ~]# curl -O http://centosmirror.go4hosting.in/centos/6.4/os/x86_64/repodata/1e584feac3f3fb76ad4b6fb7e1bc8d44fa124814e9d186dc913ded3c63a216b3-primary.sqlite.bz2  
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 4471k  100 4471k    0     0  67874      0  0:01:07  0:01:07 --:--:-- 1071k

Sometimes I am also getting the below error on some of the mirrors:

http://centos.aol.in/6.4/os/x86_64/repodata/1e584feac3f3fb76ad4b6fb7e1bc8d44fa124814e9d186dc913ded3c63a216b3-primary.sqlite.bz2: [Errno 14] PYCURL ERROR 6 - "Couldn't resolve host 'centos.aol.in'"
Trying other mirror.

As I am new to Linux and networking, any help here is much appreciated.

Solution

I could finally resolve this issue by adding timeout=300 to the /etc/yum.conf file. Thanks to all who tried to help.

Comments

[Brian]

CentOS 6 installs with the network connection in manual mode. Use ifconfig to see what interfaces are up. Use ifup eth0 to bring up that interface. Edit /etc/sysconfig/network-scripts/ifcfg-eth0 and change onboot to yes to have it brought up when the system boots.

[Siva]

@EtanReisner : I have included the results of wget to my question

[Siva]

@Brian : since I am able to do successful wget, I think the eth0 is up. But I also tried as per your suggestion but with same result. I also checked that the ONBOOT=yes is already specified in ifcfg-eth0

[Etan Reisner]

If you try the yum update again right after wget succeeds (you really should have just passed it the url and not the full error message contents as well, but oh well) does it still fail?

[Siva]

@EtanReisner : Sorry Etan, I was in a rush while doing the wget :(...I tried doing yum update right after wget succeeds but it still fails...I am also occasionally getting a PYCURL ERROR 6.

[Etan Reisner]

Do you have curl installed? What does curl -O <URL> do? Does it succeed like wget or fail like yum?

[Siva]

@EtanReisner : I have tried, curl succeeds. I have updated the question with the output.

[Etan Reisner]

You appear to be having at least some networking problems though I can't say why that would affect yum worse than wget and curl. A dump of the network traffic while yum is running might tell you something useful. You might also want to try manually finding a mirror that can work for you.

[rickhg12hs]

Any more useful info in /var/log/yum.log? What about if you increase debuglevel in yum.conf?

[Siva]

@rickhg12hs : The /var/log/yum.log is always empty even with debuglevel 10. I am not sure if i have to set the debuglevel to any other number and try.

[rickhg12hs]

@Siva : What's the output of 'yum check' and 'yum check-update'?

[Siva]

@rickhg12hs : the issue got resolved by overriding the timeout parameter. Thanks for your help.

[pokstad]

I know why you had this problem and it's the same issue I have. The corporate proxy has to download the HTTP request in its entirety before you can download it on Fedora. So the proxy is sending these keep-alives so the connection stays open (stalling while it downloads and performs any security scans). This feature is annoying if you didn't ask for it. It appears to Yum that you have a crappy download speed, but once the proxy is ready you will download at full blast.