Description of problem: Some operations on spacewalk cause a query in the database to hang in this state: postgres: spaceuser spaceschema 192.168.14.10(57927) idle in transaction It will stay there forever until manually killed. It happens with at least one specific centos5 server when running rhn_check Bellow are the queries executed on the DB: Q...:BEGIN; SET TRANSACTION ISOLATION LEVEL READ COMMITTED.Q... select 1.Q.../select label, value from rhnTemplateString.Q...` select s.id , s.secret from rhnServer s where s.id = 1000010105 .Q...V select s.id from rhnServer s where s.id = 1000010105 .Q...2select * from rhnServer where id = 1000010105.Q...F select label from rhnServerArch where id = 1023 .Q.... update rhnServerInfo set checkin = current_timestamp, checkin_counter = checkin_counter + 1 where server_id = 1000010105 .Q....COMMIT.Q...:BEGIN; SET TRANSACTION ISOLATION LEVEL READ COMMITTED.Q.... select TO_CHAR(expires, 'YYYY-MM-DD HH24:MI:SS') expires from rhnSatelliteCert where label = 'rhn-satellite-cert' order by version desc nulls last .Q...Wselect server_id, label from rhnServerEntitlementView where server_id = 1000010105.Q.... select at.label action_type, at.trigger_snapshot, at.name from rhnServerAction sa, rhnAction a, rhnActionType at where sa.server_id = 1000010105 and sa.action_id = 6731 and sa.status = 1 and a.id = 6731 and a.action_type = at.id .Q.... update rhnServerAction set status = 2, result_code = 0, result_msg = E'Files successfully diffed', completion_time = current_timestamp where action_id = 6731 and server_id = 1000010105 .Q.... update rhnActionConfigRevision set failure_id = NULL where server_id = 1000010105 and action_id = 6731 .Q...i select acr.id, cfn.path from rhnConfigFileName cfn, rhnConfigFile cf, rhnConfigRevision cr, rhnActionConfigRevision acr where acr.server_id = 1000010105 and acr.action_id = 6731 and acr.config_revision_id = cr.id and cr.config_file_id = cf.id and cf.config_file_name_id = cfn.id .Q...@select * from rhnConfigFileFailure where label = E'missing'.Q...Y update rhnActionConfigRevision set failure_id = 1 where id = 98849 .Q...Y update rhnActionConfigRevision set failure_id = 1 where id = 98673 .Q...e select acr.id from rhnActionConfigRevision acr where acr.server_id = 1000010105 This was obtained with wireshark, so there are some garbage characters in there. After the last select statement there is no further communication and a commit is not issued. That select returns 49000 records. Version-Release number of selected component (if applicable): 1.8 with Psql backend How reproducible: Always for a specific server when running rhn_check. Occasionally on other servers that run centos5 when running rhn_check Curiously, never happens with centos6 servers. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
(In reply to comment #0) > How reproducible: > Always for a specific server when running rhn_check. > Occasionally on other servers that run centos5 when running rhn_check Could you attach the output of rhn_check -vv ?
(In reply to comment #1) > > Could you attach the output of rhn_check -vv ? We seem to have communication lost. Closing, please reopen if you are able to get the output from your system.
This BZ closed some time during 2.5, 2.6 or 2.7. Adding to 2.7 tracking bug.