Bug 147619 - Taskomatic running but RHN Tools page not updating
Taskomatic running but RHN Tools page not updating
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Server (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Terry Jones
Red Hat Satellite QA List
Depends On:
  Show dependency treegraph
Reported: 2005-02-09 16:09 EST by Terry Jones
Modified: 2008-08-01 22:11 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-18 10:01:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Terry Jones 2005-02-09 16:09:52 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Description of problem:
I get the error/warning message that " It has been 2400 minutes since
the task engine ran. This may indicate a problem; please consult help
for further information." 

The values on the RHN Internal Tools page all have a date of 2 days
ago except for the Current DB Time - this is correct.

This problem used to indicate that taskomatic had stopped running.
This was rectified by restarting the service.

This isn't the case here. Taskomatic is running and handling work.
Restarting the service makes no difference to the values.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Log in to the satellite

Actual Results:  You get the message.

Expected Results:  You shouldn't get the message

Additional info:

This is the AOL satellite server so it's been around for a while. We
just upgraded from 3.2 to 3.6.
Comment 1 Robin Norwood 2005-02-10 13:46:04 EST

I can't reproduce this issue on a 3.6 satellite here.  Can you please
run through the following steps to try to narrow down the issue, and
return to me the results?

1) # service rhn-satellite restart
(Yes, I see you already restarted taskomatic, but just in case...)
2) # service taskomatic status
3) # rpm -q rhn-base perl-DBI perl-DBD-Oracle
4) # grep taskomatic /var/log/messages
5) look in /var/log/messages and see if anything interesting shows up
around the time that the internal tools page shows things last ran.
6) Verify the date/time on the satellite server *and* the db server,
if it is not an embedded db:
# date;rdate time.nist.gov
(or similar)
7) Log into the db with sqlplus:
# sqlplus rhnsat/rhnsat@rhnsat
(Use the value from 'grep default_db /etc/rhn/rhn.conf')
SQL> alter session set nls_date_format = 'YYYY-MM-DD HH24:MI:SS';
SQL> select * from rhntaskqueue;
(should be 0, or very few)
SQL> select * from rhndaemonstate;
SQL> select sysdate from dual;
(this value should match the times you verified above)
Comment 2 Terry Jones 2005-02-10 14:23:33 EST
1.  Shutting down rhn-satellite...
Stopping httpd:                                            [  OK  ]
Shutting down taskomatic:                                  [  OK  ]
Shutting down osa-dispatcher:                              [FAILED]
Shutting down Jabber router:                               [  OK  ]
Starting rhn-satellite...
Starting Jabber services                                   [  OK  ]
Starting osa-dispatcher:                                   [  OK  ]
Starting taskomatic:                                       [  OK  ]
Starting httpd: Processing config directory: /etc/httpd/conf/rhn/
 Processing config file: /etc/httpd/conf/rhn/app.conf
 Processing config file: /etc/httpd/conf/rhn/applet.conf
 Processing config file: /etc/httpd/conf/rhn/config-management-tool.conf
 Processing config file: /etc/httpd/conf/rhn/config-management.conf
 Processing config file: /etc/httpd/conf/rhn/package-push.conf
 Processing config file: /etc/httpd/conf/rhn/rhn_monitoring.conf
 Processing config file: /etc/httpd/conf/rhn/xmlrpc.conf
 Processing config file: /etc/httpd/conf/rhn/xp.conf
I tried this multiple times and osa-dispatcher FAILED each time on shutdown.

2.  service taskomatic status
taskomatic (pid
7953) is running...

3.  rpm -q rhn-base perl-DBI perl-DBD-Oracle

4. Not sure what you're looking for here - there are 1000's of taskomatic
entries in /var/log/messages.
5. At the time shown by most of the entries on the page (23:58:34) it had just
finished SynchProbeState and had started processing errata
6. Both satellite and databases machines are within a few minutes of each other
and are running ntpd. 
7. The select from rhntaskqueue returned 34860 rows

rhndaemonstate returned

LABEL                       LAST_POLL
session_cleanup             005=02-07 23:07:44
summary_populator           005=02-07 02:00:01
kickstart_session_check     005=02-07 23:12:44
errata_engine               005=02-07 23:21:37
errata_queue                005=02-07 23:58:34
sandbox_cleanup             005=02-06 10:07:56
synch_probe_state           005=02-07 23:58:34
last_task_completed         005=02-07 23:58:34
package_cleanup             005=02-07 23:12:44
summary_reaper              005=02-07 23:21:37
rhnproc                     005=02-07 15:26:27
11 rows selected.

005=02-10 14:22:39

This bugzilla has been attached to IT 65549. sysreport and satellite-debug can
be found there.
Comment 3 Terry Jones 2005-02-16 10:36:04 EST
Something hapened to cause these values to change. There is nothing in the 
error/access/xmlrpc logs to indicate what caused these values to update.

Main Task Engine:          2005-02-15 09:20:58   
Session Cleanup:           2005-02-15 09:20:56   
Errata Notification Queue: 2005-02-15 09:20:55   
Errata Notification Mail:  2005-02-15 08:42:58   
Daily Summary Queue:       2005-02-15 04:22:45   
Daily Summary Mail:        2005-02-15 08:42:58   
Clean Current Alerts:      2005-02-15 04:22:44   
Synch Probe State:         2005-02-15 08:43:00   
Errata Cache:              2005-02-15 09:21:25 
Comment 4 Terry Jones 2005-02-18 10:01:55 EST
Appears to have been an artifact of another bug.

Closing as not-a-bug.

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