Reload action on init script kills daemon

[Adam Collard]

$ pidof nagios2
29114
$ sudo /etc/init.d/nagios2 reload
 * Reloading nagios2 monitoring daemon configuration files nagios2 [ OK ]
$ pidof nagios2
$ tail /var/log/nagios2/nagios.log
[1217275349] Nagios 2.11 starting... (PID=29112)
[1217275349] LOG VERSION: 2.0
[1217275349] Finished daemonizing... (New PID=29114)
[1217275378] Caught SIGTERM, shutting down...
[1217275378] Successfully shutdown... (PID=29114)

It looks like the init script is using "killproc ... 1" from /lib/lsb/init-functions which ends up calling "start-stop-daemon --stop ..."

Manually running "kill -1 $(pidof nagios2)" successfully causes nagios to reload it's configuration files.

[Adam Collard (adam-collard)]

Whoops. nagios2 not nagios

[Thierry Carrez (ttx)]

Confirmed in hardy.

This is in fact a bug in /lib/lsb/init-functions where killproc does handle all signals as SIGTERM :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478871
The fix is already merged in intrepid.

[Thierry Carrez (ttx)]

This can be worked-around in nagios2, or fixed in lsb. The LSB change might have too much regression potential for a SRU, though.

If we want to fix it in nagios2 we can use the attached initscript patch.

[Thierry Carrez (ttx)]

This would be the patch if we choose to fix it in lsb directly.

This will change behavior of all scripts calling killproc with a signal number. This is theorically a good change, but it might generate unexpected behavior changes.

I can make a debdiff for the chosen solution.

[Thierry Carrez (ttx)]

nagios2 initscript patch if we prefer to fix it in nagios2

[Thierry Carrez (ttx)]

MOTU SRU team: could you please tell me what would make the best SRU candidate in your opinion : fixing the bug in lsb or working around it in nagios2 ? I'll then prepare the appropriate debdiffs and SRU reports.

[Dustin Kirkland  (kirkland)]

Given that the LSB patch is already upstream and available in Intrepid, and looking at the code, it is clearly the correct "technical" solution.

However, applying this change to Hardy would affect basically every init script in Ubuntu. This is not an SRU that would be accepted lightly. Heavy scrutiny would be required in order to prove that there are no regressions. If this patch to LSB solved a goodly selection of known bugs, then it might be worth pursuing that route. But Thierry says that he looked, and could not find another bug affected by this.

The patch to nagios2 itself is simple, self-contained, and appears correct as well. This would be a far easier SRU to obtain, as the chances for regression are minimal. Furthermore, Thierry has another SRU in progress (Bug #231004). I recommend rolling this patch into that SRU, with the appropriate changelog entry mentioning the current bug (Bug #252686).

Cheers,
:-Dustin

[Thierry Carrez (ttx)]

Debdiff for bug 231004 + bug 252686 SRU

Bug Impact: calling the "reload" init script action for nagios2 results in killing the daemon.

Affected supported releases: hardy. The bug in LSB has been introduced between gutsy and hardy.

Development branch fix: nagios3 is shipped with Intrepid. LSB has been fixed in intrepid so that killproc correctly transmits signals.

TEST CASE:
$ sudo apt-get install nagios2
[...]
$ pidof nagios2
5124
$ sudo /etc/init.d/nagios2 reload
 * Reloading nagios2 monitoring daemon configuration files nagios2 [ OK ]
$ pidof nagios2
$
Nagios should be running after the reload.

Regression potential discussion:
This update only impacts the reload action of the nagios2 init script, which is currently completely broken.

[Luca Falavigna (dktrkranz)]

lsb in Intrepid fixed this problem. Following Dustin's advice, it is preferable to address this in nagios2 to reduce regression potential. Intrepid is not affected: nagios2 has been superseded by nagios3.

[Luca Falavigna (dktrkranz)]

Uploaded to hardy-proposed as 2.11-1ubuntu1.3.

[ShadowMax76 (shadowmax76)]

Verification done (x86):

- nagios2 2.11-1ubuntu1.2 (hardy): reload does not work;
- nagios2 2.11-1ubuntu1.3 (hardy-proposed): reload works fine.

[Luca Falavigna (dktrkranz)]

I can confirm version 2.11-1ubuntu1.3 works as described in test case.

[Martin Pitt (pitti)]

Copied to hardy-updates.

[Mark Bergsma (mark-wikimedia)]

This bug also affects Exim4:

After a

/etc/init.d/exim4 reload

exim is sent a TERM signal, and disappears without warning.

Relevant bash trace:

+ reload_exim
+ case ${QUEUERUNNER} in
+ killproc -p /var/run/exim4/exim.pid /usr/sbin/exim4 -HUP
+ local pidfile sig status base i name_param is_term_sig
+ pidfile=
+ name_param=
+ is_term_sig=no
+ OPTIND=1
+ getopts p: opt
+ case "$opt" in
+ pidfile=/var/run/exim4/exim.pid
+ getopts p: opt
+ shift 2
+ base=exim4
+ '[' '!' /var/run/exim4/exim.pid ']'
++ echo -HUP
++ sed -e 's/^-\(.*\)/\1/'
+ sig=HUP
++ echo HUP
++ sed -e 's/^SIG\(.*\)/\1/'
+ sig=HUP
+ '[' -n HUP -o HUP = 15 -o HUP = TERM ']'
+ is_term_sig=yes
+ status=0
+ '[' '!' yes = yes ']'
+ /sbin/start-stop-daemon --stop --pidfile /var/run/exim4/exim.pid --retry 5 --quiet --oknodo

[Thierry Carrez (ttx)]

Confirming on hardy. Fixed in intrepid by the LSB bugfix.

[Thierry Carrez (ttx)]

Here is a possible patch.

--- /etc/init.d/exim4.old 2009-01-30 14:16:55.000000000 +0100
+++ /etc/init.d/exim4 2009-01-30 14:19:37.000000000 +0100
@@ -139,7 +139,8 @@
 {
   case ${QUEUERUNNER} in
     combined|no|ppp)
- killproc -p "$PIDFILE" "$DAEMON" -HUP
+ /sbin/start-stop-daemon --stop --signal HUP --pidfile "$PIDFILE" \
+ --quiet "$DAEMON"
       log_progress_msg "exim4"
       ;;
     separate)

[Tim Utschig (tim-tetro)]

Is the fix discussed in #228460 going to make it into hardy? Specifically this change to /lib/lsb/init-functions:

   - if [ -n "$sig" -o "$sig" = 15 -o "$sig" = TERM ]; then
   + if [ -z "$sig" -o "$sig" = 15 -o "$sig" = TERM ]; then

I'm encountering this bug when "/etc/init.d/freeradius reload" ends up sending SIGTERM rather than SIGHUP.

I can see that it is marked as WONTFIX for hardy. I suppose it is not a severe bug, but it is confusing when first encountered and annoying thereafter.

[Thierry Carrez (ttx)]

Tim: it's not a severe bug, but it's a risky move in an LTS, since you can't really determine all what may be affected by this change. The choice made was to selectively fix the affected packages, which is safer but more work and less comprehensive. Adding a task for freeradius/hardy.

[Thierry Carrez (ttx)]

SRU Report for freeradius

Bug Impact: calling the "reload" init script action for freeradius results in killing the daemon.

Affected supported releases: hardy. The bug in LSB has been introduced between gutsy and hardy.

Development branch fix: LSB has been fixed in intrepid so that killproc correctly transmits signals.

Minimal patch: see attached

TEST CASE:
$ sudo apt-get install freeradius
[...]
$ pidof freeradius
5124
$ sudo /etc/init.d/freeradius reload
 * Reloading configuration files for FreeRADIUS daemon...
$ pidof freeradius
$
Freeradius should be running after the reload.

Regression potential discussion:
This update only impacts the reload action of the freeradius init script, which is currently completely broken.

[Thierry Carrez (ttx)]

Subscribing ubuntu-sru for decision on hardy SRU for freeradius

[Martin Pitt (pitti)]

Thierry, the freeradius patch looks fine (equivalent to the nagios one), please upload.

[Martin Pitt (pitti)]

(In the future, please just upload simple patches like that; it's easy to reject them in the few cases where there aren't appropriate, and in general having it in the queue already speeds things up)

[Thierry Carrez (ttx)]

Uploaded.

[Steve Langasek (vorlon)]

please leave SRU bugs at 'in progress' until the uploads are accepted into -proposed.

[Martin Pitt (pitti)]

Accepted freeradius into hardy-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Thierry Carrez (ttx)]

I confirm that the version in hardy-proposed fixes the reload issue.

[Mrten (bugzilla-ii)]

This bug affects nagios3 as well, the patch from comment #4 fixes the issue.

[Thierry Carrez (ttx)]

@Mrten: nagios3 wasn't in hardy and this bug was fixed in intrepid... what version are you reproducing the bug on ?

[Mrten (bugzilla-ii)]

This is 8.04.3 LTS, looking at apt-cache policy I see I've pulled nagios3 as backport from rogerw's ppa (mentioned in bug 240764).

[Launchpad Janitor (janitor)]

This bug was fixed in the package freeradius - 1.1.7-1ubuntu0.1

---------------
freeradius (1.1.7-1ubuntu0.1) hardy-proposed; urgency=low

  * debian/freeradius.init: Fix 'reload' action so that it doesn't just
    stop the daemon (LP: #252686)

 -- Thierry Carrez <email address hidden> Mon, 15 Jun 2009 12:54:39 +0000

[Paul Elliott (omahn)]

SRU: Minimal patch to fix 'reload' action in exim4 init script

I would like to nominate this for SRU in Hardy. Newer releases do not have this issue as the underlying problem in init-functions is fixed:

https://bugs.launchpad.net/ubuntu/hardy/+source/exim4/+bug/252686/comments/2

Currently it's not possible to reload exim4 using the init script on Hardy. It currently kills the running daemon without warning. This patch fixes the behaviour of the init script by directly calling start-stop-daemon rather that using the faulty killproc function in init-scripts. Regression potential is low as the same fix has already previously been applied to both freeradius and nagios2 without issue.

TEST CASE:

1. Install and configure updated exim4.
2. Issue a '/etc/init.d/exim4 reload' - the exim4 daemon should remain running if the patch is successful.

[John Dong (jdong)]

Hi Paul,

(1) Please target hardy-proposed, not hardy
(2) Version number should be 4.69-2ubuntu0.1

Other than that, the patch looks good. Once this is fixed, consider the patch ACKed by the SRU team.

[Paul Elliott (omahn)]

Hi John,

Thanks for your pointers, I've updated the target to hardy-proposed and corrected the version number. Please find the updated debdiff attached.

Please can somebody provide sponsorship and upload to hardy-proposed for further testing?

Thanks, Paul.

[Thierry Carrez (ttx)]

@Paul: The patch looks incorrect to me. You use $PROGRAM while the original script uses $DAEMON ?

[Paul Elliott (omahn)]

@Thierry: Well spotted, strange that it still worked without the command at the end of the parameters to start-stop-daemon. Anyway, please find attached a corrected debdiff.

[Thierry Carrez (ttx)]

Uploaded, pending acceptation in hardy-proposed.

[Martin Pitt (pitti)]

Accepted exim4 into hardy-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Paul Elliott (omahn)]

The 4.69-2ubuntu0.1 package from hardy-proposed fixes the issue on my test machines. Can anyone else also provide verification?

[Launchpad Janitor (janitor)]

This bug was fixed in the package exim4 - 4.69-2ubuntu0.1

---------------
exim4 (4.69-2ubuntu0.1) hardy-proposed; urgency=low

  * debian/exim4-base.exim4.init: Fix 'reload' action so that it
    doesn't just stop the daemon (LP: #252686)
 -- Paul Elliott <email address hidden> Wed, 31 Mar 2010 22:03:05 +0100