[Asterisk-Dev] Re: is this a bug?

[Andrew Kohlsmith]

On January 26, 2005 07:51 pm, Matt Riddell wrote:
> :)  Good, at least there's a limit then!

:-)

> > This has nothing to do with clickthrough licensing nor nanny-fying
> > Asterisk. ^C is a really shitty way to stop a "daemon with a command line
> > interface" as Tlighman put it.
>
> If you were running those as a daemon *and* a command line interface,
> you wouldn't have the problem.

Not sure I follow -- there really isn't any such thing as a daemon with an 
attached CLI; the're not compatible.  Either you're backgrounded (and have no 
attached CLI) or you're foregrounded (? is that a word?) and thus not a 
daemon.

> So what happens if Asterisk crashes while you're away/asleep/on holiday?
>   Do you expect your users to have no phone until you track down the
> problem?  (I can kinda see this one coming - you a] have your own
> restart script b] have tested every possibility and know Asterisk will
> not ever crash c] your Server rings an alarm bell next to your bed and
> flashes all the house lights if it goes down or d] don't sleep/go on
> holiday)

Exactly. 

> > again defy you to find a unix application with an interactive shell that
> > quits with ^C, more and less being excepted since they are not what I'd
> > consider interactive shells.
>
> And this is worth my time how exactly?

I'm just trying to show that I don't think there is another app that behaves 
quite this way, and that by doing so Asterisk breaks the rule of least 
surprise.  I'm not saying that these are laws that must be adhered, I am 
rather trying to point out that having your PBX die by hitting ^C is most 
certainly *not* expected, and really it should not be honoured.

> > Point taken, although like I said I think yours is a very fringe case,
> > what with up-arrow pulling up the last command and all.  :-)

Well fine then, use -q(uick-quit) or --i-like-my-control-c-thankyouverymuch to 
specifically enable this behaviour.  Just because there is a console does not 
mean that ^C is an appropriate keystroke to allow to kill it.

I can see I'm not going to win this argument but in light of this, can we at 
least PRETTY PLEASE have something in the -h tell you that this is NOT how to 
run asterisk in the general case?  Or at least something in the handbook 
which states that -c will leave you high and dry?

In other words if we're not going to "fix" it in the code, can we at least 
document this (in my mind, wrong) behaviour, perhaps going out of our way to 
show that asterisk -rc is the PROPER way to initiate a CLI to asterisk?

-A.