[Home]

Summary:ASTERISK-19127: Asterisk does not quit on SIGTERM
Reporter:Byron Clark (byronclark)Labels:
Date Opened:2011-12-27 11:54:59.000-0600Date Closed:2012-01-05 09:26:02.000-0600
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Core/General
Versions:1.8.8.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:( 0) quit_on_signals.patch
Description:When starting asterisk without {{-c}} or with {{console=no}} in {{asterisk.conf}}, asterisk does not shut down in response to SIGINT or SIGTERM but happily continues running.

This bug was introduced by the fix for ASTERISK-17927.
Comments:By: Byron Clark (byronclark) 2011-12-27 11:56:11.803-0600

The attached [^quit_on_signals.patch] is a patch against 1.8.8.0 that resolves the issue. The same patch is probably necessary on the 10 and trunk branches.
By: Jonathan Rose (jrose) 2012-01-03 13:56:39.374-0600

Hey Byron, I'm having a little trouble reproducing this issue on Ubuntu 10.04. If you could supply some information regarding this, I'd appreciate it.

* Are there any conditions aside from not having a console that have to take place in order for this problem to occur? Does it happen every time you attempt to end the process with SIGINT or SIGTERM?
* Verify for me whether this seems like an appropriate way of reproducing the bug:
1. Start Asterisk 1.8.8.0 without being in console mode
2. $kill -s INT <pid of asterisk process>  (also just $kill <pid of asterisk process> for SIGTERM)
3. verify status of asterisk process

In any event, it seems to have the expected result when I'm doing it.  Asterisk shuts down, and if I have a CLI open via $asterisk -r, it shows the usual last minute cleanup stuff.
By: Byron Clark (byronclark) 2012-01-04 12:06:31.523-0600

Your steps to reproduce the bug should cause the problem. I'm not sure why they aren't. In any case, here are the steps I followed to get a clean setup and reproduce the issue.  All of these took place inside a freshly downloaded asterisk-1.8.8.1 source tree:

# ./configure --prefix=/usr/local/asterisk-19127
# make -j5
# sudo make install
# sudo make samples
# /usr/local/asterisk-19127/sbin/asterisk -vvvg
# kill -TERM $(pidof asterisk)
# *nothing happens*
# kill -KILL $(pidof asterisk)
# *asterisk dies*

If I start the test build of asterisk with the {{-c}} option then the SIGTERM works as expected.

Admittedly, I'm not running Ubuntu, but I've seen this behavior on both ArchLinux and CentOS 5.
By: Jonathan Rose (jrose) 2012-01-04 16:08:40.344-0600

Ok, this setup is a little more odd than what I was anticipating.

1.  It would appear as though you are running Asterisk without root access.  That has a number of possible implications, many of which are detailed on this page:
http://www.voip-info.org/wiki/view/Asterisk+non-root

I don't think that's what is causing the problem here though, but I just figured I'd throw that out there.

2.  Using asterisk -v implies running in no fork mode (-f) if nothing like -r or -c is used.  No fork mode appears to be ignoring signals like you are suggesting under Fedora and Ubuntu (the environments I've been testing in). But the thing is, there seems to be some other trigger.

I was able to reproduce the problem under Fedora and Ubuntu, so yeah, it's safe to say we are getting somewhere with this. I was also able to confirm the patch seemed to fix the problem in both cases.  The weird thing though is that under Ubuntu, after applying the patch, I tried to reproduce it again without the patch and I could no longer do so for some crazy reason.  That didn't happen when I tried the same stuff on Fedora.  This bug is turning out to be a weird one though regardless of all of that.  I'm going to be trying to figure out how appropriate the patch is and get a better understanding of why this happens and doesn't happen under certain circumstances over the next little while.  In any event, the key concept here is that it only actually seems to happen in no fork mode.
By: Jonathan Rose (jrose) 2012-01-04 16:28:00.103-0600

EDIT:  Ixnay to what I wrote here a few minutes ago.  I misinterpreted what was going on and Asterisk actually is quitting on signals made from kill with the patch in place.

Yeah, I think this patch is a pretty sensible way of solving this problem after all.  Thanks for the catch.  Not 100% sure though, it might actually be better to just make the condition evaluate as false in the case of no fork mode.  I'm going to sit on it until tomorrow morning though.