Fine by me.
On 20/05/2009, at 12:25 PM, Amos Jeffries wrote:
Yeah; looking through, it looks to me like a few in the auth and fs
modules need to be changed to fatal_dump; the rest (over a hundred)
don't really need a core -- they're things like config parsing errors
and self-evident error states.
I'll come up with a patch that does that and adds a FATAL_DUMPS
compile-time flag with a 0 default.
What do you mean by that last?
I think if you are going to correct the fatal() and fatal_dump()
usage it
won't be needed.
Amos
On 20/05/2009, at 11:28 AM, Mark Nottingham wrote:
The case that triggered this for me was when the log daemon dies;
doesn't make much sense to core there either.
I'll take a look through and report back.
On 20/05/2009, at 11:24 AM, Amos Jeffries wrote:
I'm going to push back on that; the administrator doesn't really
have
any need to get a core when, for example, append_domain doesn't
start
with .'.
Squid.conf is bloated as it is; if there are cases where a core
could
be conceivably useful, they should be converted to fatal_dump.
From
what I've seen they'll be a small minority at best...
That I agree with. Grep the code for all fatals and see what falls
out.
I think you will find it's only the config parser that can get away
with
non-core fatals.
Amos
On 19/05/2009, at 2:25 PM, Adrian Chadd wrote:
just make that behaviour configurable?
core_on_fatal {on|off}
Adrian
2009/5/19 Mark Nottingham <m...@yahoo-inc.com>:
tools.c:fatal() dumps core because it calls abort.
Considering that the core can be quite large (esp. on a 64bit
system), and
that there's fatal_dump() as well if you really want one, can we
just make
fatal() exit(1) instead of abort()ing?
Cheers,
--
Mark Nottingham m...@yahoo-inc.com
--
Mark Nottingham m...@yahoo-inc.com
--
Mark Nottingham m...@yahoo-inc.com
--
Mark Nottingham m...@yahoo-inc.com
--
Mark Nottingham m...@yahoo-inc.com
