Bug 834319 - RuntimeError: cannot load dispatch table from pyexpat
RuntimeError: cannot load dispatch table from pyexpat
Status: CLOSED WONTFIX
Product: Pulp
Classification: Community
Component: user-experience (Show other bugs)
1.1.0
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: John Matthews
Preethi Thomas
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-21 10:31 EDT by Matt Hermanson
Modified: 2013-09-09 12:32 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-27 10:10:46 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matt Hermanson 2012-06-21 10:31:56 EDT
Description of problem: Some of our repos (arbitrary as far I can tell) are throwing the error when they try and sync.  


Version-Release number of selected component (if applicable): 
pulp-1.1.10-1.el6.noarch

How reproducible:
Always

Steps to Reproduce:
1. Run a sync on the repo
2. Check /var/log/pulp/pulp.log
3.
  
Actual results:
Prints a traceback:
2012-06-21 10:02:04,256 15289:140653122021120: pulp.server.tasking.task:ERROR: task:472 Task failed: Task 2d272b05-bb13-11e1-b915-00505686001a: _sync(sles-11.1-x86_64-sdk-updates, synchronizer=<pulp.server.a
pi.synchronizers.YumSynchronizer object at 0x7fec5c9dcd50>, skip=SON([]), progress_callback=<bound method RepoSyncTask.progress_callback of <pulp.server.api.repo_sync_task.RepoSyncTask object at 0x7fec5c9dcd
10>>)
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/pulp/server/tasking/task.py", line 418, in run
    result = self.callable(*self.args, **self.kwargs)
  File "/usr/lib/python2.6/site-packages/pulp/server/api/repo_sync.py", line 283, in _sync
    progress_callback, synchronizer, max_speed, threads)
  File "/usr/lib/python2.6/site-packages/pulp/server/api/repo_sync.py", line 373, in fetch_content
    added_packages = synchronizer.process_packages_from_source(repo_dir, repo_id, skip_dict, progress_callback)
  File "/usr/lib/python2.6/site-packages/pulp/server/api/synchronizers.py", line 215, in process_packages_from_source
    added_packages = self.add_packages_from_dir(dir, repo_id, skip_dict)
  File "/usr/lib/python2.6/site-packages/pulp/server/api/synchronizers.py", line 235, in add_packages_from_dir
    unfiltered_pkglist = pulp.server.util.get_repo_packages(dir)
  File "/usr/lib/python2.6/site-packages/pulp/server/util.py", line 328, in get_repo_packages
    sack.populate(r, 'metadata', None, 0)
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 165, in populate
    if self._check_db_version(repo, mydbtype):
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 223, in _check_db_version
    return repo._check_db_version(mdtype)
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1256, in _check_db_version
    repoXML = self.repoXML
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1455, in <lambda>
    repoXML = property(fget=lambda self: self._getRepoXML(),
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1447, in _getRepoXML
    self._loadRepoXML(text=self)
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1437, in _loadRepoXML
    return self._groupLoadRepoXML(text, self._mdpolicy2mdtypes())
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1412, in _groupLoadRepoXML
    if self._commonLoadRepoXML(text):
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1230, in _commonLoadRepoXML
    result = self._getFileRepoXML(local, text)
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1008, in _getFileRepoXML
    size=102400) # setting max size as 100K
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 830, in _getFile
    size=size
  File "/usr/lib/python2.6/site-packages/urlgrabber/mirror.py", line 408, in urlgrab
    return self._mirror_try(func, url, kw)
  File "/usr/lib/python2.6/site-packages/urlgrabber/mirror.py", line 394, in _mirror_try
    return func_ref( *(fullurl,), **kwargs )
  File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 985, in urlgrab
    return self._retry(opts, retryfunc, url, filename)
  File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 886, in _retry
    r = apply(func, (opts,) + args, {})
  File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 980, in retryfunc
    apply(cb_func, (obj, )+cb_args, cb_kwargs)
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1494, in _checkRepoXML
    repoXML = repoMDObject.RepoMD(self.id, filepath)
  File "/usr/lib/python2.6/site-packages/yum/repoMDObject.py", line 124, in __init__
    self.parse(srcfile)
  File "/usr/lib/python2.6/site-packages/yum/repoMDObject.py", line 143, in parse
    for event, elem in parser:
  File "<string>", line 58, in __iter__
RuntimeError: cannot load dispatch table from pyexpat


Expected results:
Expected repo to sync

Additional info:
The server was recently updated to Red Hat Enterprise Linux Server release 6.3 (Santiago). Therefor python also got updated to python-2.6.6-29.el6_2.2.x86_64
Comment 1 Matt Hermanson 2012-06-21 10:43:04 EDT
I was able to produce the error when trying to sync generic-5-x86_64-pulp

Id                      generic-5-x86_64-pulp    
Name                    Generic                  
Repo URL                https://mirror2.dontworryaboutit.com/pulp/repos/repos/pulp/pulp/v1/testing/5Server/x86_64/
Feed URL                http://repos.fedorapeople.org/repos/pulp/pulp/v1/testing/5Server/x86_64/
Feed Type               remote                   
Content Type            yum                      
Feed Certs              CA:No   Cert:No
Consumer Certs          CA:No   Cert:No
Architecture            x86_64                   
Sync Schedule           2012-06-21T10:00:00-04:00/P1D
Packages                17                       
Files                   0                        
Distributions           None                     
Publish                 True                     
Clones                  [u'infra-unstable-generic-5-x86_64-pulp']
Groups                  None                     
Filters                 []                       
Notes                   {}                       
Preserve Metadata       False                    
Checksum Type           sha
Comment 2 John Matthews 2012-06-21 10:51:30 EDT
This bz 814490 may be related.
https://bugzilla.redhat.com/show_bug.cgi?id=814490

BZ mentions that an old version of libexpat was being picked up by accident, user removed the old libexpat and the problem was fixed.

Please search the server for any instances of libexpat, and remove old versions from ldconfig
Comment 3 Matt Hermanson 2012-06-21 11:06:04 EDT
(In reply to comment #2)
> This bz 814490 may be related.
> https://bugzilla.redhat.com/show_bug.cgi?id=814490
> 
> BZ mentions that an old version of libexpat was being picked up by accident,
> user removed the old libexpat and the problem was fixed.
> 
> Please search the server for any instances of libexpat, and remove old
> versions from ldconfig

This is the only version of libexpat installed on the system. 
lrwxrwxrwx. 1 root root 17 Jun 20 15:00 /lib64/libexpat.so.1 -> libexpat.so.1.5.2
Comment 4 Matt Hermanson 2012-06-26 08:29:11 EDT
(In reply to comment #3)
> (In reply to comment #2)
> > This bz 814490 may be related.
> > https://bugzilla.redhat.com/show_bug.cgi?id=814490
> > 
> > BZ mentions that an old version of libexpat was being picked up by accident,
> > user removed the old libexpat and the problem was fixed.
> > 
> > Please search the server for any instances of libexpat, and remove old
> > versions from ldconfig
> 
> This is the only version of libexpat installed on the system. 
> lrwxrwxrwx. 1 root root 17 Jun 20 15:00 /lib64/libexpat.so.1 ->
> libexpat.so.1.5.2

It looks like this bug is related to the workaround for pymongo mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=825312

We had to upgrade back to pymongo-2.1.1-1.el6.x86_64. Syncs are working normally again except for packages with a '.' in the name.
Comment 5 Jay Dobies 2012-11-27 10:10:46 EST
The 2.x releases will function correctly with pymongo 2.1 and no longer suffer from the dot in the package name issue. There are no plans for another release in the 1.x stream, so I'm closing this bug out as won't fix.

Note You need to log in before you can comment on or make changes to this bug.