Description of problem: I cannot push any package into sw Version-Release number of selected component (if applicable): sw.nightly woth oracle or with postgre spacewalk-backend-1.3.14-1.el5 How reproducible: always Steps to Reproduce: 1. install sw 2. rhnpush one package Actual results: rhnpush zsh-html-4.2.6-5.el5.x86_64.rpm -u user -p pass Internal Server Error Expected results: works well Additional info:
Created attachment 463059 [details] http_error_log , sw on postgre
sw on oracle behaves little bit different, I cannot find log like with sw on postgre: $ rhnpush zsh-4.2.6-3.el5.i386.rpm -vvv Connecting to https://localhost/APP url is https://localhost/PACKAGE-PUSH Result codes: 200 OK Computing checksum and package info. This may take some time ... Package zsh-4.2.6-3.el5.i386.rpm Not Found on RHN Server -- Uploading Uploading package zsh-4.2.6-3.el5.i386.rpm Using POST request Internal server error 500 Internal Server Error Error pushing zsh-4.2.6-3.el5.i386.rpm: Error 500Error Message: Unable to load package Error Class Code: 50 Error Class Info: Invalid information uploaded to the server (500) 1 Waiting 3 seconds and trying again... $ getenforce Permissive $ /etc/init.d/iptables status Firewall is stopped.
I believe that that RHN 16129 2010/11/26 05:42:30 -04:00: ("DATABASE CONNECTION TO 'spaceschema' LOST", "Exception information: Database instance has no attribute 'dbh'") error on PostgreSQL is caused by exhausted connections to the database. We probably should bump up the number of allowed sessions for the PostgreSQL server.
Taking. Petr, rhnpush seems to work fine both on Oracle and PostgreSQL in latest Spacewalk nightlies. Do you still see the problem on your installations? Jan
(In reply to comment #3) > I believe that that > > RHN 16129 2010/11/26 05:42:30 -04:00: ("DATABASE CONNECTION TO 'spaceschema' > LOST", "Exception information: Database instance has no attribute 'dbh'") > > error on PostgreSQL is caused by exhausted connections to the database. We > probably should bump up the number of allowed sessions for the PostgreSQL > server. Actually, the problem was caused by osa-dispatcher issuing bad SQL and then opening another connection and not closing down the previous one. The osa-dispatcher was fixed in latest nightlies.
This bug has been fixed in Spacewalk 1.3.