Core dump file control
Subsystems (3)
PATCH 1/1 Core dump file control
I have, for a long time, wished that Linux had a way to specify where core dumps are stored and what the name of the core dump is. Now that I have been building large linux clusters with many diskless nodes, this need has become even more important.
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.
The sysctl is kernel.core_name_format and is a string up to 63 characters (plus 1 for the null)
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
Only behavior of appending the PID to the "core" name is still supported with the added logic of only doing so if the PID is not already part of the name format. The default name format is still just "core" to match old behavior.
NOTE - I was tempted to change the default format to be something like "%N.core" which would at least identify the program that caused the core file. However, I can do that as part of my init process so it is not a issue here.
The attached patch is for Linux 2.4.17 but should patch relatively easily to other versions. I tried to commend the code a bit to explain the how and why.
-----------------
include/linux/sysctl.h Thu Feb 14 08:23:59 2002 renamed from include/linux/sysctl.h Mon Nov 26 08:29:17 2001 +1 -0
@@ -124,6 +124,7 @@ KERN_CORE_USES_PID=52, /* int: use core or core.%pid */ KERN_TAINTED=53, /* int: various kernel tainted flags */ KERN_CADPID=54, /* int: PID of the process to notify on CAD */ + KERN_CORE_NAME_FORMAT=55, /* string: core file name format string */ };
kernel/sysctl.c Thu Feb 14 08:26:15 2002 renamed from kernel/sysctl.c Fri Dec 21 12:42:04 2001 +3 -0
@@ -49,6 +49,7 @@ extern int max_queued_signals; extern int sysrq_enabled; extern int core_uses_pid; +extern char core_name_format[]; extern int cad_pid; /* this is needed for the proc_dointvec_minmax for [fs_]overflow UID and GID */
@@ -171,6 +172,8 @@ 0644, NULL, &proc_dointvec}, {KERN_CORE_USES_PID, "core_uses_pid", &core_uses_pid, sizeof(int), 0644, NULL, &proc_dointvec}, + {KERN_CORE_NAME_FORMAT, "core_name_format", core_name_format, 64, + 0644, NULL, &proc_doutsstring, &sysctl_string}, {KERN_TAINTED, "tainted", &tainted, sizeof(int), 0644, NULL, &proc_dointvec}, {KERN_CAP_BSET, "cap-bound", &cap_bset, sizeof(kernel_cap_t),
fs/exec.c Thu Feb 14 10:00:16 2002 renamed from fs/exec.c Fri Dec 21 12:41:55 2001 +117 -5
153 lines not on this page · raw message
Signature · 3 lines
Michael Sinz ---- Worldgate Communications ---- [email protected] A master's secrets are only as good as the master's ability to explain them to others.
Quoted 4 lines · Michael Sinz
I have, for a long time, wished that Linux had a way to specify where core dumps are stored and what the name of the core dump is. Now that I have been building large linux clusters with many diskless nodes, this need has become even more important.
...
I just wanted to throw in my 0.02 Euro on this one:
I have not yet tested your patch yet - but this functionality is *very* important to my company as well.
Anyone developing applications with multiple processes will benefit significantly from having core files named differnetly than just "core".
A patch was included in the kernel some time ago, to allow the appending of the PID - however, this is not really good enough. It's better than nothing, but it's not good.
What I want is "core.[process name]" eventually with a ".[pid]" appended. A
flexible scheme like your patch implements is very nice. Actually having
the core files in CWD is fine for me - I mainly care about the file name.
Furthermore, the patch that went in earlier is *horrible* code. Let me give a few examples:
...
char corename[6+sizeof(current->comm)+10];
...
memcpy(corename,"core.", 5);
corename[4] = '\0';
...
if (core_uses_pid || atomic_read(¤t->mm->mm_users) != 1)
sprintf(&corename[4], ".%d", current->pid);Enough said.
Signature · 6 lines
................................................................ : [email protected] : And I see the elder races, : :.........................: putrid forms of man : : Jakob Østergaard : See him rise and claim the earth, : : OZ9ABN : his downfall is at hand. : :.........................:............{Konkhra}...............:
Quoted 17 lines · Jakob Østergaard
Quoted 5 lines · Michael Sinz
I have, for a long time, wished that Linux had a way to specify where core dumps are stored and what the name of the core dump is. Now that I have been building large linux clusters with many diskless nodes, this need has become even more important.
...
I just wanted to throw in my 0.02 Euro on this one:
I have not yet tested your patch yet - but this functionality is *very* important to my company as well.
Anyone developing applications with multiple processes will benefit significantly from having core files named differnetly than just "core".
Quoted 8 lines
A patch was included in the kernel some time ago, to allow the appending of the PID - however, this is not really good enough. It's better than nothing, but it's not good.
What I want is "core.[process name]" eventually with a ".[pid]" appended. A
flexible scheme like your patch implements is very nice. Actually having
the core files in CWD is fine for me - I mainly care about the file name.
Please execute the size command on the core fiel:
size core
to see why this isn't needed.
Quoted 1 line
Quoted 8 lines · Jakob Østergaard
Quoted 4 lines · Michael Sinz
I have, for a long time, wished that Linux had a way to specify where core dumps are stored and what the name of the core dump is. Now that I have been building large linux clusters with many diskless nodes, this need has become even more important.
...
Quoted 7 lines
I just wanted to throw in my 0.02 Euro on this one:
I have not yet tested your patch yet - but this functionality is *very* important to my company as well.
Anyone developing applications with multiple processes will benefit significantly from having core files named differnetly than just "core".
That was my first need (%N.core is what I used on a different platform) However, being able to specify a few more items really provides much more flexibility.
Quoted 10 lines
A patch was included in the kernel some time ago, to allow the appending of the PID - however, this is not really good enough. It's better than nothing, but it's not good.
What I want is "core.[process name]" eventually with a ".[pid]" appended. A
flexible scheme like your patch implements is very nice. Actually having
the core files in CWD is fine for me - I mainly care about the file name.Furthermore, the patch that went in earlier is *horrible* code. Let me give a few examples:
I had noticed that - it was rather poor - and rather strange. I hope people like my patch a bit better.
Signature · 3 lines
Michael Sinz ---- Worldgate Communications ---- [email protected] A master's secrets are only as good as the master's ability to explain them to others.
Quoted 28 lines · Martin Dalecki
Quoted 17 lines · Jakob Østergaard
Quoted 5 lines · Michael Sinz
I have, for a long time, wished that Linux had a way to specify where core dumps are stored and what the name of the core dump is. Now that I have been building large linux clusters with many diskless nodes, this need has become even more important.
...
I just wanted to throw in my 0.02 Euro on this one:
I have not yet tested your patch yet - but this functionality is *very* important to my company as well.
Anyone developing applications with multiple processes will benefit significantly from having core files named differnetly than just "core".
Quoted 7 lines
A patch was included in the kernel some time ago, to allow the appending of the PID - however, this is not really good enough. It's better than nothing, but it's not good.
What I want is "core.[process name]" eventually with a ".[pid]" appended. A
flexible scheme like your patch implements is very nice. Actually having
the core files in CWD is fine for me - I mainly care about the file name.
Quoted 5 lines
Please execute the size command on the core fiel:
size core
to see why this isn't needed.
Huh? explain... If I have multiple programs running and one cores, would I not want to have the core file name be based on the program that cored? Linux had the PID option (kernel.core_uses_pid) specifically so that you could have multiple process core files.
Plus, I need to be able to redirect core files to a sane location in the cluster (which is a whole other kettle of fish).
Signature · 3 lines
Michael Sinz ---- Worldgate Communications ---- [email protected] A master's secrets are only as good as the master's ability to explain them to others.
Quoted 1 line · Martin Dalecki
Jakob Østergaard wrote:
...
Quoted 6 lines
Quoted 5 lines
What I want is "core.[process name]" eventually with a ".[pid]" appended. A
flexible scheme like your patch implements is very nice. Actually having
the core files in CWD is fine for me - I mainly care about the file name.
Quoted 6 lines
Please execute the size command on the core fiel:
size core
to see why this isn't needed.
Huh ?
I suppose you mean, that I can get the name of the executable that caused the core dump, when running size - right ?
Well, you can do that easier with the file command.
But that doesn't prevent my 7 other processes from overwriting the core file
of the 8'th process which was the first one to crash. Multi-process systems
can, on occation, produce such "domino dumps". Separate names is a *must have*.
And having process names is nicer than having PIDs - I don't mind if my core files are over-written on subsequent runs, actually it's nice (keeps the disks from filling up).
Signature · 6 lines
................................................................ : [email protected] : And I see the elder races, : :.........................: putrid forms of man : : Jakob Østergaard : See him rise and claim the earth, : : OZ9ABN : his downfall is at hand. : :.........................:............{Konkhra}...............:
Quoted 19 lines · Jakob Østergaard
Quoted 2 lines · Martin Dalecki
Jakob Østergaard wrote:
...
Quoted 10 lines
Quoted 4 lines
What I want is "core.[process name]" eventually with a ".[pid]" appended. A
flexible scheme like your patch implements is very nice. Actually having
the core files in CWD is fine for me - I mainly care about the file name.Please execute the size command on the core fiel:
size core
to see why this isn't needed.
Huh ?
Quoted 9 lines
I suppose you mean, that I can get the name of the executable that caused the core dump, when running size - right ?
Well, you can do that easier with the file command.
But that doesn't prevent my 7 other processes from overwriting the core file
of the 8'th process which was the first one to crash. Multi-process systems
can, on occation, produce such "domino dumps". Separate names is a *must have*.
This point I fully agree with. And in fact 2.4.17 already does it the core.{pid} way.
Quoted 4 lines
And having process names is nicer than having PIDs - I don't mind if my core files are over-written on subsequent runs, actually it's nice (keeps the disks from filling up).
They can get long and annoying... They are not suitable for short name filesystems... They provide a good hint for deliberate overwrites.... and so on. Basically I think this would be too much of the good.
Quoted 1 line
Quoted 1 line · Martin Dalecki
Jakob Østergaard wrote:
..
Quoted 9 lines
Quoted 5 lines
And having process names is nicer than having PIDs - I don't mind if my core files are over-written on subsequent runs, actually it's nice (keeps the disks from filling up).
They can get long and annoying... They are not suitable for short name filesystems... They provide a good
hint for deliberate overwrites.... and so on. Basically I think this would be too much of the good.
That is your oppinion, and I disagree.
And that is *exactly* why the suggested patch is so great - we just keep the "core" name the default, and allow the user to set the name as he pleases.
Signature · 6 lines
................................................................ : [email protected] : And I see the elder races, : :.........................: putrid forms of man : : Jakob Østergaard : See him rise and claim the earth, : : OZ9ABN : his downfall is at hand. : :.........................:............{Konkhra}...............:
Quoted 25 lines · Martin Dalecki
Quoted 22 lines · Jakob Østergaard
Quoted 2 lines · Martin Dalecki
Jakob Østergaard wrote:
...
Quoted 10 lines
Quoted 4 lines
What I want is "core.[process name]" eventually with a ".[pid]" appended. A
flexible scheme like your patch implements is very nice. Actually having
the core files in CWD is fine for me - I mainly care about the file name.Please execute the size command on the core fiel:
size core
to see why this isn't needed.
Huh ?
I suppose you mean, that I can get the name of the executable that caused the core dump, when running size - right ?
Quoted 8 lines
Quoted 6 lines
Well, you can do that easier with the file command.
But that doesn't prevent my 7 other processes from overwriting the core file
of the 8'th process which was the first one to crash. Multi-process systems
can, on occation, produce such "domino dumps". Separate names is a *must have*.This point I fully agree with. And in fact 2.4.17 already does it the core.{pid} way.
This is still not a very good way to control the names.
What I have is a cluster of nearly 100 machines - all but one of them have no disk. When something goes down on one of the machines, I would like to know (a) what it was that went down and (b) which machine it was on. I would also like to have the core files someplace that is writable (all but the /coredumps directory is read-only - oh, and the local tmpfs mounts for /var and /etc)
Quoted 8 lines
Quoted 3 lines
And having process names is nicer than having PIDs - I don't mind if my core files are over-written on subsequent runs, actually it's nice (keeps the disks from filling up).
They can get long and annoying... They are not suitable for short name filesystems... They provide a good
hint for deliberate overwrites.... and so on. Basically I think this would be too much of the good.
I was very carefull to keep that behavior consistant with 2.4.17. That is, if you do nothing different with the kernel.core_name_format then it will work just as before. And only root can change that sysctl.
As to "overwrites" and the like, I have much less overwrites with most any pattern form than with just plain "core" And I can support features that many people have wanted (%N.core being a very popular construct).
Signature · 3 lines
Michael Sinz ---- Worldgate Communications ---- [email protected] A master's secrets are only as good as the master's ability to explain them to others.