Bug 483156 - random 500 errors when using yum from client
random 500 errors when using yum from client
Status: CLOSED DUPLICATE of bug 503584
Product: Spacewalk
Classification: Community
Component: Server (Show other bugs)
0.5
All Linux
low Severity medium
: ---
: ---
Assigned To: Pradeep Kilambi
Mike McCune
:
Depends On:
Blocks: space05
  Show dependency treegraph
 
Reported: 2009-01-29 16:11 EST by Mike McCune
Modified: 2009-06-10 08:49 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-25 13:40:39 EDT
Type: ---
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 Mike McCune 2009-01-29 16:11:13 EST
received these errors when running yum search osad:


[Thu Jan 29 14:57:45 2009] [error] [client 127.0.0.1] PythonHeaderParserHandler server.apacheServer::HeaderParserHandler: Traceback (most recent call last):
[Thu Jan 29 14:57:45 2009] [error] [client 127.0.0.1] PythonHeaderParserHandler server.apacheServer::HeaderParserHandler:   File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 287, in HandlerDispatch\n    log=debug)
[Thu Jan 29 14:57:45 2009] [error] [client 127.0.0.1] PythonHeaderParserHandler server.apacheServer::HeaderParserHandler:   File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 461, in import_module\n    f, p, d = imp.find_module(parts[i], path)
[Thu Jan 29 14:57:45 2009] [error] [client 127.0.0.1] PythonHeaderParserHandler server.apacheServer::HeaderParserHandler: ImportError: No module named apacheServer
[Thu Jan 29 14:57:45 2009] [error] [client 127.0.0.1] PythonLogHandler server.apacheServer::LogHandler: Traceback (most recent call last):
[Thu Jan 29 14:57:45 2009] [error] [client 127.0.0.1] PythonLogHandler server.apacheServer::LogHandler:   File "/usr/lib/python2.4/site-packages/mod_python/apache.py", lin
e 287, in HandlerDispatch\n    log=debug)
[Thu Jan 29 14:57:45 2009] [error] [client 127.0.0.1] PythonLogHandler server.apacheServer::LogHandler:   File "/usr/lib/python2.4/site-packages/mod_python/apache.py", lin
e 461, in import_module\n    f, p, d = imp.find_module(parts[i], path)
[Thu Jan 29 14:57:45 2009] [error] [client 127.0.0.1] PythonLogHandler server.apacheServer::LogHandler: ImportError: No module named apacheServer
[Thu Jan 29 14:57:45 2009] [error] [client 127.0.0.1] PythonCleanupHandler server.apacheServer::CleanupHandler: Traceback (most recent call last):
[Thu Jan 29 14:57:45 2009] [error] [client 127.0.0.1] PythonCleanupHandler server.apacheServer::CleanupHandler:   File "/usr/lib/python2.4/site-packages/mod_python/apache.
py", line 287, in HandlerDispatch\n    log=debug)
[Thu Jan 29 14:57:45 2009] [error] [client 127.0.0.1] PythonCleanupHandler server.apacheServer::CleanupHandler:   File "/usr/lib/python2.4/site-packages/mod_python/apache.
py", line 461, in import_module\n    f, p, d = imp.find_module(parts[i], path)
[Thu Jan 29 14:57:45 2009] [error] [client 127.0.0.1] PythonCleanupHandler server.apacheServer::CleanupHandler: ImportError: No module named apacheServer
Comment 1 John Hodrien 2009-01-30 05:14:42 EST
Observed this too (thought I'd filed this, but apparently not).  I found this to be slightly confusing, as the yum operation would sometimes succeed and sometimes fail.  The absence of these errors made success guaranteed, but the presence of them didn't always equate to failure.

In my case, a restart of all services has made this go away for now, so I've found further investigation difficult.

In my case physical memory availability on the machine is tight, although there's plenty of swap free.
Comment 2 Tim Tedford 2009-01-30 12:57:01 EST
The problem has persisted through restarts for me, and appears to be affecting all operations against the repo. Here is a sample error from a scheduled job:

   1.
      This action will be executed after 01/30/09 11:46:24 AM CST.
   2.
       
   3.
      This action's status is: Failed.
   4.
      The client picked up this action on 01/30/09 11:46:25 AM CST.
   5.
      The client completed this action on 01/30/09 11:47:11 AM CST.
   6.
      Client execution returned "Error while executing packages action: Error Downloading Packages: rhncfg-client - 5.2.0-0.el5.noarch: failed to retrieve getPackage/rhncfg-client-5.2.0-0.el5.noarch.rpm from centos5-base-i386 error was [Errno 14] HTTP Error 500: Internal Server Error [[6]]" (code -1)
   7.
      Packages Scheduled:
   8.
       
   9.
          * rhncfg-client-5.2.0-0.el5
  10.
          * rhncfg-5.2.0-0.el5
  11.
          * rhncfg-actions-5.2.0-0.el5
Comment 3 Partha Aji 2009-02-12 20:10:13 EST
Apparently the backend complains "ImportError: No module named apacheServ" for any error. But the debug level is set to 1 in the default install. Due to this we donot have sufficient  information to track this error.. So the next time we need to s/debug=1/debug=5 in /etc/rhn/default/rhn_server.conf to actually have apache print the actual stack trace...


Error like
[..~]# yum search osadas
Loading "security" plugin
Loading "rhnplugin" plugin
Error: Cannot retrieve repository metadata (repomd.xml) for repository: rhel-i386-server-5. Please verify its path and try again

Only mean that yum server took a long time to respond to the client due to either creating cache or some other machine issue... 
Assigning this to prad :)..
Comment 5 Pradeep Kilambi 2009-03-25 13:40:39 EDT
I tested on 0.5 install as well and dont seem to get any errors if have a fully functinal install of spacewalk. closing..
Comment 6 Jason Czerak 2009-06-02 11:24:59 EDT
I have this error. I'm running the latest version of python/apache/tomcat from RHEL/OEL 5.3. I've had this issues for a few days. This morning I had errors until I turned debugging on 5.  Other then large amounts of debug logs,  My issues disappeared.
Comment 7 Pradeep Kilambi 2009-06-10 08:49:56 EDT

*** This bug has been marked as a duplicate of bug 503584 ***

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