The ideas I have seen so far are fine for the person proposing them, I'm
looking for a much more general system which each site can tweak to suit its
requirements. Simple instancing is vulnerable to denial of service, adding
the command name can overwrite non-core files as well as loosing earlier
dumps. Neither keeps track of dumps nor notifies anybody.
Coming from the mainframe world where core dumps are treated with concern
(at least if the sysprog is awake :) and mechanisms have already evolved
to handle repetitive dumps while avoiding denial of service, I see no
shame in pinching their ideas. Consider the following :-
1) All core dumps are initially communicated from the kernel to a daemon
(coredumpd) through socket /dev/coredumpd.
2) If coredumpd is not running or the dump is for coredump itself, dump
as core (no change).
3) coredumpd looks at the dump information (failing program, user, core
ulimit, directory, registers etc.) and compares it against its site
defined rules to see what should be done with this dump. coredumpd
also looks at its history file to see if this dump has already occurred,
again site defined as to how many "duplicate" dumps to keep and how
recent an earlier dump must be to suppress the new dump. Finally
coredump looks at how many total dumps have occured recently, too many
too soon could be denial of service.
4) Given the above site defined hueristics, coredump tells the kernel to
ignore the dump or to dump it. In the latter case coredump also
supplies the filename which could even be in another directory. In
either case coredump updates its history file of dumps and optionally
mails somebody about the problem.
Should be a fairly small change to the kernel, mainly in xxx_core_dump
routines. I see coredumpd being written in perl 5 to take full
advantage of its regular expressions and to make it easier for sites to
enhance it. Slower than C but the decision about whether to dump or
not is not exactly speed critical.
Please email.
Keith Owens