core file naming option

Alan et. all,

The attached patch adds an option to the build to have core files named core.processname, but defaulting to the current behaviour of course. For most people the single 'core' file is sufficient, but when the sky is falling, it's nice to have more places for it to land. :) So, is this something that might go into the kernel, or are their philisophical reasons against it? (The patch is against 2.2.19. I haven't looked at 2.4.x yet. Let me know if you want a 2.4 or if I should send it to Linus, or...)

Questions, comments, etc. welcome,

Eli
--------------------. Real Users find the one combination of bizarre
Eli Carter \ input values that shuts down the system for days.
eli.carter(a)inet.com `-------------------------------------------------

diff -urN linux.orig/Documentation/Configure.help linux/Documentation/Configure.help
@@ -8765,6 +8765,12 @@
   from within Linux if you have also said Y to "UFS filesystem
   support", above.
 
+Long corefile names
+CONFIG_COREFILE_LONGNAME
+  If you say Y here, core files will be named 'core.[process]' where
+  '[process]' is the name of the process which dumped core.
+  Otherwise, they will be named 'core' by default.
+
 ADFS filesystem support (read only) (EXPERIMENTAL)
 CONFIG_ADFS_FS
   The Acorn Disc Filing System is the standard filesystem of the

diff -urN linux.orig/fs/Config.in linux/fs/Config.in
@@ -6,6 +6,7 @@
 
 bool	 'Quota support' CONFIG_QUOTA
 tristate 'Kernel automounter support' CONFIG_AUTOFS_FS
+bool     'Long corefile names' CONFIG_COREFILE_LONGNAME
 
 
 if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then

diff -urN linux.orig/fs/binfmt_elf.c linux/fs/binfmt_elf.c
@@ -1140,7 +1140,7 @@
 	set_fs(KERNEL_DS);
 
 	memcpy(corefile,"core.",5);
-#if 0
+#ifdef CONFIG_COREFILE_LONGNAME
 	memcpy(corefile+5,current->comm,sizeof(current->comm));
 #else
 	corefile[4] = '\0';

Other Unix' have used core.pid as the name. Wouldn't this be better? Especially when the process name is already stored in a core file (file core will give you this). Hmm I wonder could we use this core.pid format to dump the core for each thread (probably a bad idea).

Padraig.

The -ac tree and latest -linus can use core.pid for each thread already

Ah, I see: /proc/sys/kernel/core_uses_pid if I'm not mistaken.

However, my primary interest is with the 2.2.x series, and I don't see this in 2.2.19.
Is this something that will be moving to 2.2.19? Are there philisophical or technical reasons one way or the other?

Thank you for your time,

Eli
--------------------. Real Users find the one combination of bizarre
Eli Carter \ input values that shuts down the system for days.
eli.carter(a)inet.com `-------------------------------------------------

Eli-

Having the 2.2.x series create core.pid' is like a 2 line change to fs/binfmt_elf.c', just increase the size of the array that holds the file name and sprintf' the pid into it. I've got a patch for the 2.2.x series that dumps core for all threads and puts them in core.pid' files.

Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/652-0870x117

Well, when I asked Alan about it, he said "Doing it in 2.2 is incredibly hard for internal locking reasons"... I'm not ready to tackle that. If you have a patch that does it correctly, submit it to Alan. I'd still like to have the option I submitted as part of 2.2 *shrug*... it's just bringing back functionality that was in earlier versions of Linux as a compile option. (From what I understand, this is similar to something done in the BSDs at some time in the past... but being a young whippersnapper, I don't really know.)

Eli
--------------------. Real Users find the one combination of bizarre
Eli Carter \ input values that shuts down the system for days.
eli.carter(a)inet.com `-------------------------------------------------

In article <[email protected]>,
Eli Carter <[email protected]> wrote:

| The attached patch adds an option to the build to have core files named
| core.processname, but defaulting to the current behaviour of course. 
| For most people the single 'core' file is sufficient, but when the sky
| is falling, it's nice to have more places for it to land.  :)
| So, is this something that might go into the kernel, or are their
| philisophical reasons against it?  (The patch is against 2.2.19.  I
| haven't looked at 2.4.x yet.  Let me know if you want a 2.4 or if I
| should send it to Linus, or...)
| 
| Questions, comments, etc. welcome,

Since you asked for it... ;-)

While you're adding this feature, and it seems others are adding
similar things, it is *highly* desirable to allow the build to put all the dumps in one place of desired (my first thought is /var/core) so that if you get a lot you won't run the system out of disk.

The directory name could be set in /proc/sys/coredir (or somesuch)
with an initial value of "." of course.

Other than that I like the idea, although process "name" could get a
lot of clashes on threads, and pid gets reused. There may be a better idea, but most of mine are cumbersome. This would really simplify certain kinds of dump analysis.

bill davidsen <[email protected]>
 "If I were a diplomat, in the best case I'd go hungry.  In the worst
  case, people would die."
		-- Robert Lipe

Thanks. :)

I can see that those would be good improvements... but core.name is what I can do (and get the time to do,) right now.

Eli
--------------------. Real Users find the one combination of bizarre
Eli Carter \ input values that shuts down the system for days.
eli.carter(a)inet.com `-------------------------------------------------