Bug 490783 - Disabling Satellite results in incessant cronjob mailings re: "SatCluster.ini"
Disabling Satellite results in incessant cronjob mailings re: "SatCluster.ini"
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Server (Show other bugs)
530
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Lestach
Jeff Browning
: Regression
Depends On:
Blocks: 463877
  Show dependency treegraph
 
Reported: 2009-03-17 20:56 EDT by Corey Welton
Modified: 2009-09-10 14:49 EDT (History)
3 users (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-10 14:49:13 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 Corey Welton 2009-03-17 20:56:22 EDT
Description of problem:
If you shut down the satellite service(s), a cronjob continues to run, and spews an error report every 15 minutes about a missing init file that appears to get (re)created everytime the satellite is initiated.

See "Additional Info" for more analysis.


Version-Release number of selected component (if applicable):
Satellite-5.3.0-RHEL5-re20090306.2-i386.iso

How reproducible:
Every time.... I think.

Steps to Reproduce:
1.  Start satellite and let it run for a while.
2.  Shutdown satellite.
3.  Observe email in the mailbox assigned to root on satellite host cron

  
Actual results:
Emails, every 15 minutes, akin to the following:


Subject: Cron <nocpulse@rlx-0-12>  if [ -e /etc/NOCpulse.ini ] ; then /usr/bin/monitor-queue ALERTS 50 100 2>&1 > /dev/null; fi
Date: Tue, 17 Mar 2009 20:30:02 -0400

Failed to open /etc/nocpulse/SatCluster.ini: No such file or directory at /usr/lib/perl5/vendor_perl/5.8.8/NOCpulse/SatCluster.pm line 51

Expected results:
No emails -- something should be cleaned up to assure that users don't get these cronjob notes when server is not running.

Additional info:

Note the following analysis:
[root@rlx-0-12 ~]# ls -alF /etc/nocpulse/SatCluster.ini ; /usr/sbin/rhn-satellite stop ; ls -alF /etc/nocpulse/SatCluster.ini
-rw-r--r-- 1 root root 102 Mar 17 20:38 /etc/nocpulse/SatCluster.ini
Shutting down rhn-satellite...
Stopping RHN Taskomatic...
Stopped RHN Taskomatic.
Stopping cobbler daemon:                                   [  OK  ]
Stopping rhn-search...
Stopped rhn-search.
Stopping MonitoringScout ...  Stopping Dispatcher ...  [ OK ]
Stopping Dequeuer ...  [ OK ]
Stopping SputLite ...  [ OK ]
Stopping NPBootstrap ...  [ OK ]
Stopping InstallSoftwareConfig ...  [ OK ]
[ OK ]
Stopping Monitoring ...  Stopping TSDBLocalQueue ...  [ OK ]
Stopping AckProcessor ...  [ OK ]
Stopping Notifier ...  [ OK ]
Stopping NotifLauncher ...  [ OK ]
Stopping NotifEscalator ...  [ OK ]
Stopping GenerateNotifConfig ...  [ OK ]
[ FAIL ]
[ OK ]
Stopping httpd:                                            [  OK  ]
Stopping tomcat5:                                          [  OK  ]
Shutting down osa-dispatcher:                              [  OK  ]
Shutting down Jabber router:                               [  OK  ]
Done.
ls: /etc/nocpulse/SatCluster.ini: No such file or directory


When the server is running, "SatCluster.ini" exists.  When satellite is shutdown, this file disappears.  However, a continuous cronjob looks for this file, regardless as to whether the satellite is up or not.
Comment 4 Miroslav Suchý 2009-03-19 13:40:55 EDT
Well, I *think* that the problem is caused by several recent changes of mine.

To be precise with commits:
6288db727ebc4460d2628d060b6d4c8f7fbf42a6
e9b92eaeed70090cec629d8570c1aab19053ab71

Only two days ago I find that some Scout initalization/configuratio is done in 
 code/src/com/redhat/rhn/domain/monitoring/satcluster/SatCluster.java
as well. And those two probably collides.
So I will had to revert one or other (java or perl) code and revisit both affected bugs. And note that BZ 490235 is probably related as well.
Comment 5 Miroslav Suchý 2009-04-06 10:00:18 EDT
Note to myself:
After the steps to reproduce I have there:
 # cat  /etc/nocpulse/SatCluster.ini
 [garbage]

So it is not empty. The same content is after and before stop. I'm not able to reproduce it.
Can you try it again and give better pointer how to reproduce it?
Comment 6 Corey Welton 2009-04-06 21:24:22 EDT
Be sure you have monitoring (and perhaps monitoring scout) enabled.

I did so, and repro'd with latest build

[root@rlx-0-12 ~]# ls -alF /etc/nocpulse/SatCluster.ini; /usr/sbin/rhn-satellite stop ; ls -alF /etc/nocpulse/SatCluster.ini
-rw-r--r-- 1 root root 102 Apr  6 21:20 /etc/nocpulse/SatCluster.ini
Shutting down rhn-satellite...
Stopping RHN Taskomatic...
Stopped RHN Taskomatic.
Stopping cobbler daemon:                                   [  OK  ]
Stopping rhn-search...
Stopped rhn-search.
Stopping MonitoringScout ...  Stopping Dispatcher ...  [ OK ]
Stopping Dequeuer ...  [ OK ]
Stopping SputLite ...  [ OK ]
Stopping NPBootstrap ...  [ OK ]
Stopping InstallSoftwareConfig ...  [ OK ]
[ OK ]
Stopping Monitoring ...  Stopping TSDBLocalQueue ...  [ OK ]
Stopping AckProcessor ...  [ OK ]
Stopping Notifier ...  [ OK ]
Stopping NotifLauncher ...  [ OK ]
Stopping NotifEscalator ...  [ OK ]
Stopping GenerateNotifConfig ...  [ OK ]
[ FAIL ]
[ OK ]
Stopping httpd:                                            [  OK  ]
Shutting down osa-dispatcher:                              [  OK  ]
Shutting down Jabber router:                               [FAILED]
Done.
ls: /etc/nocpulse/SatCluster.ini: No such file or directory
Comment 7 Corey Welton 2009-04-06 21:26:34 EDT
Meant to include this - I agree, "SatCluster.ini" does not appear to disappear IF user has not enabled monitoring.
Comment 8 Tomas Lestach 2009-05-05 06:31:40 EDT
I managed to reproduce the problem on an older Satellite 5.3 (compose from March).

But the problem doesn't show up on newer versions. I checked:
Satellite-5.3.0-RHEL5-re20090414.0
Satellite-5.3.0-RHEL5-re20090422.0
where I didn't see the described misbehaviour.
Comment 9 Jeff Browning 2009-06-22 17:56:27 EDT
Reproduced this using Satellite-5.3.0-RHEL5-re20090612.0-i386-embedded-oracle.iso

Disabling the Sat caused the repeating Cron job as described above.
Comment 10 Tomas Lestach 2009-06-24 09:41:49 EDT
I reproduced described behaviour. 

Config file /etc/nocpulse/SatCluster.ini gets deleted, when shutting down MonitoringScout (or the whole satellite).
Even if monitor-queue creates the config file before using it (when it doesn't exist), it has not the rights to create it when running from cron as nocpulse user.

Fix: When the config file was not created, it won't be used. Missing config file does not harm the functionality of monitor-queue.

Commit:e525be888ea322e4c503bf99db59f2986ffe4765
Comment 11 Tomas Lestach 2009-06-29 06:54:42 EDT
Available in composes since Satellite-5.3.0-RHELx-re20090625.0
Comment 12 Jeff Browning 2009-07-02 13:47:58 EDT
Verified. No cron emails after shutting down satellite this time.
Comment 13 John Sefler 2009-08-04 13:53:48 EDT
Re-verified build 7/24

Steps described in the problem description did not produce any emails.

Trying to force a re-create of the original error (Failed to open /etc/nocpulse/SatCluster.ini: No such file or directory ....), I deleted /etc/nocpulse/SatCluster.ini and manually executed /usr/bin/monitor-queue to see if it would throw the "Fail to open" error.  It did not throw the error and therefore did not send any email.  In fact, it re-created the file  /etc/nocpulse/SatCluster.ini with one line of contents: [garbage]

moving to RELEASE_PENDING
Comment 14 Brandon Perkins 2009-09-10 14:49:13 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1434.html

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