'/etc/init.d/nagios2 reload' causes nagios to exit (sends SIGTERM not SIGHUP)

Bug #236373 reported by Matt Brown
4
Affects Status Importance Assigned to Milestone
nagios2 (Ubuntu)
Fix Released
Low
Nicolas Valcarcel

Bug Description

Binary package hint: nagios2

The init script for nagios kills nagios when the user requests the configuration to be reloaded. Nagios logs that it has received a SIGTERM rather than the expected SIGHUP.

This appears to be a bug in the nagios2 (2.11-1ubuntu1) packages interaction with the lsb-base package in Hardy. This bug is not present in Debian with the 2.11-1 version of the nagios package.

The nagios init script calls killproc from the lsb-base scripts, passing it "1" (HUP) as the signal to send to nagios, the lsb-base scripts convert this to a TERM instead of a HUP.

I do not know if this is a bug in the lsb-base scripts, or the scripts being called incorrectly by the nagios init script, so I have filed this bug on Nagios as I suspect it is the more likely candidate to be at fault, it will be amazing if such a large bug in lsb-release managed to slip through the QA for an LTS release!

To reproduce the bug on a Hardy system you can do the following:

1) Install nagios2
2) Start nagios, check that it is running, tail /var/log/nagios2/nagios.log
3) In another console run, /etc/init.d/nagios2 reload
4) Observe the following lines in the log file

[1212255142] Nagios 2.11 starting... (PID=24439)
[1212255142] LOG VERSION: 2.0
[1212255142] Finished daemonizing... (New PID=24440)
< reload command is executed at this point>
[1212256400] Caught SIGTERM, shutting down...
[1212256401] Successfully shutdown... (PID=24440)

I have attached a patch that works around this issue by modifying the init script to send a HUP directly rather than using the killproc method from the lsb-base scripts. When this patch is applied the correct behaviour is observed in the nagios log file after executing /etc/init.d/nagios2 reload

[1212256426] Nagios 2.11 starting... (PID=27947)
[1212256426] LOG VERSION: 2.0
[1212256427] Finished daemonizing... (New PID=27948)
< reload command is executed at this point>
[1212257232] Caught SIGHUP, restarting...
[1212257232] Nagios 2.11 starting... (PID=27948)
[1212257232] LOG VERSION: 2.0

Related branches

Revision history for this message
Matt Brown (mattbrown) wrote :
Revision history for this message
Nicolas Valcarcel (nvalcarcel) wrote :

I can reproduce the bug, the reload command causes nagios to shotdown, not even restart.

Changed in nagios2:
assignee: nobody → nvalcarcel
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Nicolas Valcarcel (nvalcarcel) wrote :

Uploading merge for intrepid with the patch included.

Changed in nagios2:
importance: Medium → Low
Revision history for this message
Albert Damen (albrt) wrote :

Please note this is actually a bug in lsb, which doesn't properly handle signals passed to killproc.
This has been fixed in Debian (lsb 3.2-12), so a merge of lsb will fix this in Intrepid.
See bug 228460.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nagios2 - 2.11-1.1ubuntu1

---------------
nagios2 (2.11-1.1ubuntu1) intrepid; urgency=low

  * Merge from debian unstable, remaining changes:
    * debian/nagios2-common.nagios2.init
      - Fix init script pid file. (LP: #174466)
    * Update maintainers as per spec.
  * debian/nagios2-common.nagios2.init
    - Fix reload so it doesnt kill nagios. Thanks to Matt Brown and
      Nicolas Vialcaircel. (LP: #236373)

nagios2 (2.11-1.1) unstable; urgency=low

  * Non-maintainer upload to fix pending l10n issues.
  * Debconf translations:
    - Hungarian. Closes: #459377
    - Italian. Closes: #448898
    - Swedish. Closes: #460199
    - Dutch. Closes: #466442
    - Finnish. Closes: #476881
    - Galician. Closes: #478138

 -- Chuck Short <email address hidden> Wed, 21 May 2008 11:46:01 +0100

Changed in nagios2:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.