Bug 889231 - Spacewalk with Postgresql backend with "idle in transaction" processes in the DB
Summary: Spacewalk with Postgresql backend with "idle in transaction" processes in the DB
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Spacewalk
Classification: Community
Component: Server
Version: 1.8
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jan Pazdziora
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: space27
TreeView+ depends on / blocked
 
Reported: 2012-12-20 14:57 UTC by Jorge Luis
Modified: 2017-09-28 17:56 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-23 16:44:54 UTC
Embargoed:


Attachments (Terms of Use)

Description Jorge Luis 2012-12-20 14:57:02 UTC
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:

Comment 1 Jan Pazdziora 2012-12-21 07:34:50 UTC
(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 ?

Comment 2 Jan Pazdziora 2013-02-23 16:44:54 UTC
(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.

Comment 3 Eric Herget 2017-09-28 17:56:16 UTC
This BZ closed some time during 2.5, 2.6 or 2.7.  Adding to 2.7 tracking bug.


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