Re: Core dumps, patch

Jeremy Fitzhardinge (jeremy@zip.com.au)
Sat, 02 Mar 1996 16:59:57 +1100


Uwe Ohse wrote:
>
> This patch adds:
> - alternative naming for core dumps ("core", "core.command",
> "core.command.pid", "core.pid"). The later three will not overwrite
> existing files (overwriting of "core" can be disabled, too).
> - the possibility to restrict core dumps to uid 0.
> - the possibility to en/disable the generation of core dumps on the fly.
> - a sysctl interface (/proc/sys/kern/coredump).
> - a compile time option to disable core dumps altogether.
>
> usage: echo $value >/proc/sys/kern/coredump
> "value" is a bitfield, with the bits defined in fs.h. Examples:
> value: result
> 0 disable generation of core dumps. Any value with bit 0
> cleared has that effect.
> 1 "core". This is the default.
> 3 "core.command"
> 7 "core.command.pid"
> 9 "core", but only processes with uid 0 may dump core
> 19 "core.command". If that exists "core" will be written
> (overwritten if it exists).
> 33 "core", but that will nether be overwritten if it exists
> (if "gdb prog core" crashed, "core" won't get destroyed).
>
> I would like a better interface, possibly like this:
> echo "+comm +pid -overwrite" >/proc/sys/kern/coredump
> but that would be too much kernel bloat, i think.

Quite; I wouldn't bother.

Some other suggestions: instead of patching all binfmt_*.c files,
have a common core name generation function which the individual
core dumpers call.

Rather than having a CONFIG option to exclude the dumpers altogether,
have an option to either have just the simple "core" name, or all
the new functionality.

Another idea is to have a /proc/sys/kern/coredump file which you
can cat a format string into to generate a name. While I think this
is excessive bloat, it may be useful to something. For example:

%p - pid
%e - executable name
%s - sequence number (incremented every coredump since boot time)
%d - timestamp (decimal seconds since epoch; no need for full time/date
formatting).
%% - traditional '%'

[ Note, these are just made up on the spot; one could probably argue
for better codes, but that's just detail. ]

Then you could do things like:

echo core > coredump # traditional behaviour
echo core.%e > coredump # For those who like it
echo %e.core > coredump # And the others
echo %e.core.%s.%p.%d > coredump# Just because we can

As I said, I think this is unjustifiable bloat, but people obviously
get excited by this, and a solution like this allows them do do things
without having the kernel define a policy which will make someone upset.
It should definitely be a config option.

Note that '%s' overrides the need for an "inhibit core overwrites",
especially with '%d' (unless you're playing with your system time a
lot).

I don't see a need for root-only coredumps or enabling or disabling:
both these can be done already with the limits interface.

J