kernel 2.4.19 & 2.5.38 - coredump sysctl
PATCH 1/1 kernel 2.4.19 & 2.5.38 - coredump sysctl
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.
Quoted 6 lines · Michael Sinz
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.
Quoted 8 lines
...
%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 "%"
Quoted 4 lines
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?
Quoted 6 lines · Michael Sinz
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.
Quoted 9 lines
...
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 "%"
Quoted 5 lines
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?
Quoted 30 lines · Andrew Morton
Quoted 5 lines · Michael Sinz
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.
Quoted 9 lines
...
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 "%"Quoted 5 lines
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:
Quoted 7 lines
if (
core_name_formatis unset)
use "core"
else
use core_name_format/nodename-uid-pid-comm.corewhich 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.
Signature · 3 lines
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.
Quoted 14 lines · Michael Sinz
...
Quoted 9 lines
Does it need to be this fancy? Why not just have:
if (
core_name_formatis unset)
use "core"
else
use core_name_format/nodename-uid-pid-comm.corewhich 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.
Quoted 7 lines
There are some people who use a format of:
%N.%P.corewhich 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
Quoted 3 lines
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?
Quoted 14 lines · Michael Sinz
...
Quoted 9 lines
Does it need to be this fancy? Why not just have:
if (
core_name_formatis unset)
use "core"
else
use core_name_format/nodename-uid-pid-comm.corewhich 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.
Quoted 7 lines
There are some people who use a format of:
%N.%P.corewhich 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
Quoted 3 lines
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?
Quoted 37 lines · Andrew Morton
Quoted 14 lines · Michael Sinz
...
Quoted 9 lines
Does it need to be this fancy? Why not just have:
if (
core_name_formatis unset)
use "core"
else
use core_name_format/nodename-uid-pid-comm.corewhich 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.
Quoted 7 lines
There are some people who use a format of:
%N.%P.corewhich 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_pathQuoted 3 lines
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.
Quoted 3 lines
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 ;^)
Signature · 3 lines
Michael Sinz ---- Technology and Engineering Director/Consultant "Starting Startups" mailto:[email protected] My place on the web ------->> http://www.sinz.org/Michael.Sinz
Quoted 17 lines · Andrew Morton
That seems a reasonable thing to want to do.
Quoted 9 lines
...
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 "%"Quoted 5 lines
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"
Quoted 6 lines
Does it need to be this fancy? Why not just have:
if (
core_name_formatis 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.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 27 lines · Bill Davidsen
Quoted 17 lines · Andrew Morton
That seems a reasonable thing to want to do.
Quoted 9 lines
...
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 "%"Quoted 5 lines
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"
Quoted 6 lines
Does it need to be this fancy? Why not just have:
if (
core_name_formatis unset)
use "core"
else
use core_name_format/nodename-uid-pid-comm.core
Quoted 6 lines
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.
Quoted 27 lines · Bill Davidsen
Quoted 17 lines · Andrew Morton
That seems a reasonable thing to want to do.
Quoted 9 lines
...
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 "%"Quoted 5 lines
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"
Quoted 6 lines
Does it need to be this fancy? Why not just have:
if (
core_name_formatis unset)
use "core"
else
use core_name_format/nodename-uid-pid-comm.core
Quoted 6 lines
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.)
Quoted 10 lines
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 :-()
Signature · 3 lines
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.