[Asterisk-Dev] is this a bug?

[Chris Wade]

Nick Bachmann wrote:
> Chris Wade wrote:
> 
>> Did any of you actually check what -c does?  It runs asterisk in 
>> console mode providing a CLI instead of daemon mode where it 
>> immediately forks itself away from the controlling terminal.  If you 
>> run asterisk with -c it MUST (read should according to standards) 
> 
> 
> What standard is that?
> 

The standard set by 99% of apps that fit the same usage profile as 
asterisk (mind you there aren't that many).  Most programs that offer 
daemon mode and console mode react the way asterisk does, it stops when 
you hit ^C.

>> behave like any other linux process terminal and respond in some way 
>> to ^C (in fact if it doesn't itself, linux will - by killing the 
>> process).
> 
> 
> Huh? Ctrl+C just sends a signal (SIGINT) to the process.  What the 
> program does with the signal is up to it... if it doesn't exit, the 
> kernel isn't going to kill it.
> 

Write a program in <insert your favorite language here>, don't 
specifically handle SIGINT, what happens?  In *most* languages the 
process will exit - you have to specifically handle SIGINT and make sure 
not to exit if you don't want to exit on a SIGINT.  So, technically, the 
kernel didn't kill it, it just sent the signal, but it still results in 
the kernel asking for and - typically - getting the process to exit. 
(semantics anyway)

>>   And as for what * does when it sees ^C, it doesn't die with any 
>> error other than a message from its input handling routines saying 
>> input was interrupted (which is what ^C is by the way - an INTERRUPT).
> 
> 
> In fact, it's a signal... the interrupt signal (that might be why they 
> called it SIGINT :).

Again, semantics.  Yes its a signal, but as you stated it is the 
interrupt signal, therefore it is an interrupt (software sense).

Please, we've digressed OT here - lets allow this horse to die please. 
As I stated in a previous post, if the -user can reproduce the crash, 
post it on mantis after the -user list reviews his config files.

-Chris

PS: Nick, your right on most things above - I just chose different 
semantics for my descriptions - maybe I shouldn't have dumbed down my 
words for this list - it is the -dev list after all.  Kudos to you 
regardless.