Re: [RFC] --disable-panics configuration option
So all libraries should actually issue error instead of panic, because
libraries
cannot know is error fatal or not ? (But the error looks severe,
however).
Simple change would be easy to implement, and Jon is not only one
getting
strange octstr panics.
Aarno
On 24.3.2005, at 00:12, Stipe Tolj wrote:
Aarno Syvänen wrote:
And I cannot agree more, actually. But auditing takes time. Until
it is done, --disable-panics will be of some use.
now, yes, auditing takes some time. But it's the way to go, IMO.
Simply adding a configure switch would cause in unstable internal
state if a function hits the panic() button and we keep the beast
running, since the logic has in mind that the beast is supposed to die
now.
You could #idef things inside panic() to prevent it from panic'ing, if
it's up for a fast solution.
If we add the configure switch, I almost see unnecessary bug reports
rushing in that have their cause from such situations. Which I'd like
definetly to prevent.
Hence, -0 to -1 in simply blind-mode preventing panic() stops here.
+1 on auditing and making Kalle's dream come true: a genuine panic()
policy ;)
Stipe
mailto:stolj_{at}_wapme.de
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---
Re: [RFC] --disable-panics configuration option
Aarno, So all libraries should actually issue error instead of panic, because libraries cannot know is error fatal or not ? (But the error looks severe, however). Simple change would be easy to implement, and Jon is not only one getting strange octstr panics. As an aside of sorts, that's how I write all of my code. An error is passed up the 'stack' until it reaches someone that knows how major of an issue it is and whom can act accordingly. I didn't suggest an audit/partial re-write because of the scope of that sort of a thing, but if you guys are up for it, that's obviously the best way to do it. Jon
Re: [RFC] --disable-panics configuration option
Aarno Syvänen wrote:
There actually seems to two kinds of panic:
a) Configuration errors. In this case, continuation really is impossible.
b) Libs has some sanity checks that cause panic. If we just have a broken
message, we must just ignore message, not panic.
thats right. That's how Jörg understands and unnecessary panic, since a broken
message does not mean an broken internal operational state.
IMO, we should throw panics if we're unable to carry on with stable operation,
otherwise dump error, discard whatever could not be done, and continue operation.
Hence +1 on autiting panics for recoverable states.
Stipe
mailto:stolj_{at}_wapme.de
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---
Re: [RFC] --disable-panics configuration option
Alexander Malysh wrote:
I'm really -1 for disabling panics. if some places use panics but could
continue then it's a bug and those places should be fixed. panic may _only_
be used if no recovery possible.
correct. Hence summerizing:
* keep panic(), it should be _only_ use in places that can't be recovered for
normal operation.
* audit all panic()s and revert those that can keep the process in stable
operation to errors.
Stipe
mailto:stolj_{at}_wapme.de
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---
Re: [RFC] --disable-panics configuration option
Aarno Syvänen wrote:
And I cannot agree more, actually. But auditing takes time. Until
it is done, --disable-panics will be of some use.
now, yes, auditing takes some time. But it's the way to go, IMO. Simply adding a
configure switch would cause in unstable internal state if a function hits the
panic() button and we keep the beast running, since the logic has in mind that
the beast is supposed to die now.
You could #idef things inside panic() to prevent it from panic'ing, if it's up
for a fast solution.
If we add the configure switch, I almost see unnecessary bug reports rushing
in that have their cause from such situations. Which I'd like definetly to prevent.
Hence, -0 to -1 in simply blind-mode preventing panic() stops here. +1 on
auditing and making Kalle's dream come true: a genuine panic() policy ;)
Stipe
mailto:stolj_{at}_wapme.de
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---
Re: [RFC] --disable-panics configuration option
Yes. --disable-panics should be only a stopgap. One truly must know what messages are causing the panics. It actually can be just an error of the phone . On 16.3.2005, at 17:52, Jonathan Houser wrote: Aarno, There actually seems to two kinds of panic: a) Configuration errors. In this case, continuation really is impossible. b) Libs has some sanity checks that cause panic. If we just have a broken message, we must just ignore message, not panic. I would like it if a panic just wrote the appropriate lines to the log (for debugging) and kept on running. The panic's I've seen were for things that pertained to a WDP message from some phone on the WAP gateway. If that one phone doesn't get his fetch handled, oh well, we should log that we had a problem and keep on running. So I like the idea you've proposed. It'd allow everyone to work through issues without having a wrapper script work overtime. Jon
Re: [RFC] --disable-panics configuration option
And I cannot agree more, actually. But auditing takes time. Until it is done, --disable-panics will be of some use. Aarno On 16.3.2005, at 18:09, Pommnitz, Jörg wrote: But this just confirms what I wrote: such a panic is obviously inappropriate and should be replaced by a warning. So, I stand by what I wrote earlier: just audit the panics and make sure Kannel panics in only *REALLY* hopeless situations. This would IMHO be the Right Thing (TM) to do. Regards Joerg -Ursprüngliche Nachricht- Von: Jonathan Houser [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 16. März 2005 17:52 An: Aarno Syvänen Cc: Kannel list Betreff: Re: [RFC] --disable-panics configuration option Aarno, There actually seems to two kinds of panic: a) Configuration errors. In this case, continuation really is impossible. b) Libs has some sanity checks that cause panic. If we just have a broken message, we must just ignore message, not panic. I would like it if a panic just wrote the appropriate lines to the log (for debugging) and kept on running. The panic's I've seen were for things that pertained to a WDP message from some phone on the WAP gateway. If that one phone doesn't get his fetch handled, oh well, we should log that we had a problem and keep on running. So I like the idea you've proposed. It'd allow everyone to work through issues without having a wrapper script work overtime. Jon
RE: [RFC] --disable-panics configuration option
On Wed, 2005-03-16 at 19:09, Pommnitz, Jörg wrote: But this just confirms what I wrote: such a panic is obviously inappropriate and should be replaced by a warning. So, I stand by what I wrote earlier: just audit the panics and make sure Kannel panics in only *REALLY* hopeless situations. This would IMHO be the Right Thing (TM) to do. I fully agree here. It is so bad that Kannel PANICs when it is not really a PANIC situation, but we should not make things worse by allowing it to continue when it really panics because of some unrecoverable problems (I recall rising this issue of 'too easily used panics' many months ago..) -- Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
Re: [RFC] --disable-panics configuration option
There actually seems to two kinds of panic: a) Configuration errors. In this case, continuation really is impossible. b) Libs has some sanity checks that cause panic. If we just have a broken message, we must just ignore message, not panic. Aarno On 16.3.2005, at 15:02, Pommnitz, Jörg wrote: Uhh, isn't a panic supposed to be a condition where there is no recovery? Restarting Kannel might be a better option for production use than a system with an untrustworthy internal state. To propose an alternative: How about auditing all panics to make sure they really represent a condition with no way out opposed to just a programmer too lazy to unwind a complicated code flow? Regards Joerg -Ursprüngliche Nachricht- Von: Aarno Syvänen [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 16. März 2005 14:57 An: Kannel list Betreff: [RFC] --disable-panics configuration option Hi List, can we add --disable-panics configuration option ? it would mean that Kannel would log panic level error, but would not exit. This would be very good for production use. In addition, I think that --with-defaults options other than debug should disable panics too. Aarno
RE: [RFC] --disable-panics configuration option
But this just confirms what I wrote: such a panic is obviously inappropriate and should be replaced by a warning. So, I stand by what I wrote earlier: just audit the panics and make sure Kannel panics in only *REALLY* hopeless situations. This would IMHO be the Right Thing (TM) to do. Regards Joerg -Ursprüngliche Nachricht- Von: Jonathan Houser [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 16. März 2005 17:52 An: Aarno Syvänen Cc: Kannel list Betreff: Re: [RFC] --disable-panics configuration option Aarno, There actually seems to two kinds of panic: a) Configuration errors. In this case, continuation really is impossible. b) Libs has some sanity checks that cause panic. If we just have a broken message, we must just ignore message, not panic. I would like it if a panic just wrote the appropriate lines to the log (for debugging) and kept on running. The panic's I've seen were for things that pertained to a WDP message from some phone on the WAP gateway. If that one phone doesn't get his fetch handled, oh well, we should log that we had a problem and keep on running. So I like the idea you've proposed. It'd allow everyone to work through issues without having a wrapper script work overtime. Jon
