coredump name format control via sysctl
Provides for a way to securely move where core files show up and to
set the name pattern for core files to include the UID, Program,
Hostname, and/or PID of the process that caused the core dump.
This is very handy for diskless clusters where all of the core
dumps go to the same disk and for production servers where core
dumps want to be segregated from the main production disks.
I have again updated the patch to work with 2.4.19 and 2.5.36
kernels and am now hosting it on my web site at:
http://www.sinz.org/Michael.Sinz/Linux/
-- Patch background and how it works --
What I did with this patch is provide a new sysctl that lets you
control the name of the core file. The this name is actually a format
string such that certain values from the process can be included.
If the sysctl is not used to change the format string, the behavior
is exactly the same as the current kernel coredump behavior.
The default name format is set to "core" to match the current
behavior of the kernel. Old behavior of appending the PID to
the "core" name is also preserved with added logic of only doing
so if the PID is not already part of the name format. This fully
preserves current behaviors within the system while still providing
for the full control of the format of the core file name. Thus
current behavior is not a special case but "falls out" of the
general code when the format is set to "core".
The following format options are available in that string:
%P The Process ID (current->pid)
%U The UID of the process (current->uid)
%N The command name of the process (current->comm)
%H The nodename of the system (system_utsname.nodename)
%% A "%"
For example, in my clusters, I have an NFS R/W mount at /coredumps
that all nodes have access to. The format string I use is:
sysctl -w "kernel.core_name_format=/coredumps/%H-%N-%P.core"
This then causes core dumps to be of the format:
/coredumps/whale.sinz.org-badprogram-13917.core
I used upper case characters to reduce the chance of getting confused
with format() characters and to be somewhat simular to the mechanism
that exists on FreeBSD.
Michael Sinz wrote:
>
> coredump name format control via sysctl
>
> Provides for a way to securely move where core files show up and to
> set the name pattern for core files to include the UID, Program,
> Hostname, and/or PID of the process that caused the core dump.
That seems a reasonable thing to want to do.
> ...
> The following format options are available in that string:
>
> %P The Process ID (current->pid)
> %U The UID of the process (current->uid)
> %N The command name of the process (current->comm)
> %H The nodename of the system (system_utsname.nodename)
> %% A "%"
>
> For example, in my clusters, I have an NFS R/W mount at /coredumps
> that all nodes have access to. The format string I use is:
>
> sysctl -w "kernel.core_name_format=/coredumps/%H-%N-%P.core"
>
Does it need to be this fancy? Why not just have:
if (core_name_format is unset)
use "core"
else
use core_name_format/nodename-uid-pid-comm.core
which saves all that string format processing, while giving
people everything they could want?
Michael Sinz wrote:
>
> coredump name format control via sysctl
>
> Provides for a way to securely move where core files show up and to
> set the name pattern for core files to include the UID, Program,
> Hostname, and/or PID of the process that caused the core dump.
Seems a reasonable thing to want to do.
> ...
>
> %P The Process ID (current->pid)
> %U The UID of the process (current->uid)
> %N The command name of the process (current->comm)
> %H The nodename of the system (system_utsname.nodename)
> %% A "%"
>
> For example, in my clusters, I have an NFS R/W mount at /coredumps
> that all nodes have access to. The format string I use is:
>
> sysctl -w "kernel.core_name_format=/coredumps/%H-%N-%P.core"
Does it need to be this fancy? Why not just have:
if (core_name_format is unset)
use "core"
else
use core_name_format/nodename-uid-pid-comm.core
which saves all that string format processing, while giving
people everything they could want?
Andrew Morton wrote:
> Michael Sinz wrote:
>
>>coredump name format control via sysctl
>>
>>Provides for a way to securely move where core files show up and to
>>set the name pattern for core files to include the UID, Program,
>>Hostname, and/or PID of the process that caused the core dump.
>
>
> That seems a reasonable thing to want to do.
>
>
>>...
>>The following format options are available in that string:
>>
>> %P The Process ID (current->pid)
>> %U The UID of the process (current->uid)
>> %N The command name of the process (current->comm)
>> %H The nodename of the system (system_utsname.nodename)
>> %% A "%"
>>
>>For example, in my clusters, I have an NFS R/W mount at /coredumps
>>that all nodes have access to. The format string I use is:
>>
>> sysctl -w "kernel.core_name_format=/coredumps/%H-%N-%P.core"
>>
>
>
> Does it need to be this fancy? Why not just have:
>
> if (core_name_format is unset)
> use "core"
> else
> use core_name_format/nodename-uid-pid-comm.core
>
> which saves all that string format processing, while giving
> people everything they could want?
Well, it depends on if you really need the complex form or not.
There are some people who use a format of:
%N.%P.core
which places the core file in the current directory but adds in the
name of the program. (Something that is very nice when you have
a lot of programs that may core "together" when something bad happens)
The string processing is not that much work anyway (very small)
and, given the fact that I am about to write to disk a core dump,
it can not be a critical path/fast path issue either :-)
What can be done at the default pattern level in later kernels
would be to make it a bit more than just "core" (such as maybe
the "%N.%P.core" or something like that) but that is not that
complex.
Also, FreeBSD (yes, I know, it is not Linux) has a very simular
feature that we used for the FreeBSD clusters we built.
--
Michael Sinz -- Director, Systems Engineering -- Worldgate Communications
A master's secrets are only as good as
the master's ability to explain them to others.
Michael Sinz wrote:
>
> ...
> > Does it need to be this fancy? Why not just have:
> >
> > if (core_name_format is unset)
> > use "core"
> > else
> > use core_name_format/nodename-uid-pid-comm.core
> >
> > which saves all that string format processing, while giving
> > people everything they could want?
>
> Well, it depends on if you really need the complex form or not.
>
> There are some people who use a format of:
>
> %N.%P.core
>
> which places the core file in the current directory but adds in the
> name of the program. (Something that is very nice when you have
> a lot of programs that may core "together" when something bad happens)
They could use
echo . > /proc/sys/vm/core_path
> The string processing is not that much work anyway (very small)
> and, given the fact that I am about to write to disk a core dump,
> it can not be a critical path/fast path issue either :-)
True, but it's all more code and I don't believe that it adds
much value. It means that people need to run off and find
the documentation, then choose a format. Which will be different
from other people's chosen formats. Which will make development
and testing and installation of downstream scripts harder, etc.
You can give people *all* the options at no cost, and without
irritating them, and with less code. So why make it harder for
everyone by adding this optionality?
Michael Sinz wrote:
>
> ...
> > Does it need to be this fancy? Why not just have:
> >
> > if (core_name_format is unset)
> > use "core"
> > else
> > use core_name_format/nodename-uid-pid-comm.core
> >
> > which saves all that string format processing, while giving
> > people everything they could want?
>
> Well, it depends on if you really need the complex form or not.
>
> There are some people who use a format of:
>
> %N.%P.core
>
> which places the core file in the current directory but adds in the
> name of the program. (Something that is very nice when you have
> a lot of programs that may core "together" when something bad happens)
They could use
echo . > /proc/sys/vm/core_path
> The string processing is not that much work anyway (very small)
> and, given the fact that I am about to write to disk a core dump,
> it can not be a critical path/fast path issue either :-)
True, but it's all more code and I don't believe that it adds
much value. It means that people need to run off and find
the documentation, then choose a format. Which will be different
from other people's chosen formats. Which will make development
and testing and installation of downstream scripts harder, etc.
You can give people *all* the options at no cost, and without
irritating them, and with less code. So why make it harder for
everyone by adding this optionality?
Andrew Morton <[email protected]> writes:
> True, but it's all more code and I don't believe that it adds
> much value. It means that people need to run off and find
One useful feature of it would be that you can get core dumps for
each thread by including the pid (or tid later with newer threading libraries)
Currently threads when core dumping overwrite each others cores so you lose
the registers of all but one.
Doing multithreaded coredump correctly is a lot more code than this.
Another useful application of an arbitary path name would be dumping to a
named pipe and having a dr.watson that logs the backtrace to the system log
(of course this has interesting deadlock possibilities when you're not
careful...)
I would find the feature useful.
-Andi
Andi Kleen wrote:
>
> Andrew Morton <[email protected]> writes:
>
> > True, but it's all more code and I don't believe that it adds
> > much value. It means that people need to run off and find
>
> One useful feature of it would be that you can get core dumps for
> each thread by including the pid (or tid later with newer threading libraries)
> Currently threads when core dumping overwrite each others cores so you lose
> the registers of all but one.
Oh sure, I agree that it's a useful feature. But I don't agree that
we need to allow users to specify how the final filename is pasted
together. Just give them host-uid-gid-comm.core. ie: everything.
On Fri, 20 Sep 2002 14:53:24 -0700, Andrew Morton wrote:
>Michael Sinz wrote:
>>
>> ...
>> > Does it need to be this fancy? Why not just have:
>> >
>> > if (core_name_format is unset)
>> > use "core"
>> > else
>> > use core_name_format/nodename-uid-pid-comm.core
>> >
>> > which saves all that string format processing, while giving
>> > people everything they could want?
>>
>> Well, it depends on if you really need the complex form or not.
>>
>> There are some people who use a format of:
>>
>> %N.%P.core
>>
>> which places the core file in the current directory but adds in the
>> name of the program. (Something that is very nice when you have
>> a lot of programs that may core "together" when something bad happens)
>
>They could use
>
> echo . > /proc/sys/vm/core_path
>
>> The string processing is not that much work anyway (very small)
>> and, given the fact that I am about to write to disk a core dump,
>> it can not be a critical path/fast path issue either :-)
>
>True, but it's all more code and I don't believe that it adds
>much value. It means that people need to run off and find
>the documentation, then choose a format. Which will be different
>from other people's chosen formats. Which will make development
>and testing and installation of downstream scripts harder, etc.
>
>You can give people *all* the options at no cost, and without
>irritating them, and with less code. So why make it harder for
>everyone by adding this optionality?
Yes, it could be a bit smaller by removing the format string.
You still need to do all of the string concat work abeit without
the check for what you do next.
Is that really the best way to go? Does it really add that much to
the documentation overhead? (Which reminds me that I should add
some documentation to the patch ;^)
--
Michael Sinz ---- Technology and Engineering Director/Consultant
"Starting Startups" mailto:[email protected]
My place on the web ------->> http://www.sinz.org/Michael.Sinz
On Fri, Sep 20, 2002 at 04:27:24PM -0700, Andrew Morton wrote:
> Andi Kleen wrote:
> >
> > Andrew Morton <[email protected]> writes:
> >
> > > True, but it's all more code and I don't believe that it adds
> > > much value. It means that people need to run off and find
> >
> > One useful feature of it would be that you can get core dumps for
> > each thread by including the pid (or tid later with newer threading libraries)
> > Currently threads when core dumping overwrite each others cores so you lose
> > the registers of all but one.
>
> Oh sure, I agree that it's a useful feature. But I don't agree that
> we need to allow users to specify how the final filename is pasted
> together. Just give them host-uid-gid-comm.core. ie: everything.
That wouldn't support the Dr.Watson thing.
-Andi
Andi Kleen <[email protected]> :
> On Fri, Sep 20, 2002 at 04:27:24PM -0700, Andrew Morton wrote:
[...]
> > Oh sure, I agree that it's a useful feature. But I don't agree that
> > we need to allow users to specify how the final filename is pasted
> > together. Just give them host-uid-gid-comm.core. ie: everything.
>
> That wouldn't support the Dr.Watson thing.
Time to upgrade to directory notification enabled Dr.Watson ?
--
Ueimor
On Fri, 20 Sep 2002, Andrew Morton wrote:
> That seems a reasonable thing to want to do.
>
> > ...
> > The following format options are available in that string:
> >
> > %P The Process ID (current->pid)
> > %U The UID of the process (current->uid)
> > %N The command name of the process (current->comm)
> > %H The nodename of the system (system_utsname.nodename)
> > %% A "%"
> >
> > For example, in my clusters, I have an NFS R/W mount at /coredumps
> > that all nodes have access to. The format string I use is:
> >
> > sysctl -w "kernel.core_name_format=/coredumps/%H-%N-%P.core"
> >
>
> Does it need to be this fancy? Why not just have:
>
> if (core_name_format is unset)
> use "core"
> else
> use core_name_format/nodename-uid-pid-comm.core
Because this way you can do more things with where you put your dumps,
such as using one element of this flexible method to select a directory,
where the dump directories for various applications would be on a single
NFS server, and dumps for another might be on another server, or all dumps
of a certain kind could share a filename, where only the latest dump would
be of interest (or take space).
The code seems to have very little overhead involved in the parse, and it
gives a good deal of flexibility to the admin. I like the idea of a sysctl
for setting the value, you don't want to have to reboot the system when an
app goes sour and you need to save more than one dump to run it down, or
need to mvoe the dump target dir somewhere with more space.
If you're worried about size make it a compile option, but if I (as an
admin) need any control I really want a bunch of control I can set right
now. I don't think most people will want this option, but it would be
really useful in some cases.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
Bill Davidsen wrote:
>
> On Fri, 20 Sep 2002, Andrew Morton wrote:
>
> > That seems a reasonable thing to want to do.
> >
> > > ...
> > > The following format options are available in that string:
> > >
> > > %P The Process ID (current->pid)
> > > %U The UID of the process (current->uid)
> > > %N The command name of the process (current->comm)
> > > %H The nodename of the system (system_utsname.nodename)
> > > %% A "%"
> > >
> > > For example, in my clusters, I have an NFS R/W mount at /coredumps
> > > that all nodes have access to. The format string I use is:
> > >
> > > sysctl -w "kernel.core_name_format=/coredumps/%H-%N-%P.core"
> > >
> >
> > Does it need to be this fancy? Why not just have:
> >
> > if (core_name_format is unset)
> > use "core"
> > else
> > use core_name_format/nodename-uid-pid-comm.core
>
> Because this way you can do more things with where you put your dumps,
> such as using one element of this flexible method to select a directory,
> where the dump directories for various applications would be on a single
> NFS server, and dumps for another might be on another server, or all dumps
> of a certain kind could share a filename, where only the latest dump would
> be of interest (or take space).
OK, I'll buy that one.
Bill Davidsen wrote:
> On Fri, 20 Sep 2002, Andrew Morton wrote:
>
>>That seems a reasonable thing to want to do.
>>
>>>...
>>>The following format options are available in that string:
>>>
>>> %P The Process ID (current->pid)
>>> %U The UID of the process (current->uid)
>>> %N The command name of the process (current->comm)
>>> %H The nodename of the system (system_utsname.nodename)
>>> %% A "%"
>>>
>>>For example, in my clusters, I have an NFS R/W mount at /coredumps
>>>that all nodes have access to. The format string I use is:
>>>
>>> sysctl -w "kernel.core_name_format=/coredumps/%H-%N-%P.core"
>>>
>>
>>Does it need to be this fancy? Why not just have:
>>
>> if (core_name_format is unset)
>> use "core"
>> else
>> use core_name_format/nodename-uid-pid-comm.core
>
>
> Because this way you can do more things with where you put your dumps,
> such as using one element of this flexible method to select a directory,
> where the dump directories for various applications would be on a single
> NFS server, and dumps for another might be on another server, or all dumps
> of a certain kind could share a filename, where only the latest dump would
> be of interest (or take space).
Ahh, I never thought of using the program name for a directory. That
would be nice as only those programs you pre-made a directory for would
dump (as the code does not create directories). Using the UID for a
directory name works out to separate the dumps of different users.
(And works really well too - albeit on a non-Linux platform that happens
to have a simular feature.)
> The code seems to have very little overhead involved in the parse, and it
> gives a good deal of flexibility to the admin. I like the idea of a sysctl
> for setting the value, you don't want to have to reboot the system when an
> app goes sour and you need to save more than one dump to run it down, or
> need to mvoe the dump target dir somewhere with more space.
>
> If you're worried about size make it a compile option, but if I (as an
> admin) need any control I really want a bunch of control I can set right
> now. I don't think most people will want this option, but it would be
> really useful in some cases.
I would be willing to do the work to make it configurable but when I
look at the size of the code, it really is not that large. I tried
to keep it simple (KISS is always good). I still need to write up the
documentation side of this into the patch too. (I keep forgetting
to do that :-()
--
Michael Sinz -- Director, Systems Engineering -- Worldgate Communications
A master's secrets are only as good as
the master's ability to explain them to others.