[PATCH] core file naming option

[PATCH] core file naming option

[Eli Carter]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

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 `-------------------------------------------------

[-- Attachment #2: corefile.patch --]
[-- Type: text/plain, Size: 1429 bytes --]

diff -urN linux.orig/Documentation/Configure.help linux/Documentation/Configure.help
--- linux.orig/Documentation/Configure.help	Tue Sep 25 17:02:27 2001
+++ linux/Documentation/Configure.help	Tue Sep 25 16:54:23 2001
@@ -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
--- linux.orig/fs/Config.in	Tue Sep 25 17:02:34 2001
+++ linux/fs/Config.in	Tue Sep 25 16:53:08 2001
@@ -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
--- linux.orig/fs/binfmt_elf.c	Tue Sep 25 17:02:34 2001
+++ linux/fs/binfmt_elf.c	Tue Sep 25 16:53:08 2001
@@ -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';

Re: [PATCH] core file naming option

[Padraig Brady]

Eli Carter wrote:

>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,
>
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.

Re: [PATCH] core file naming option

[Alan Cox]

> 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).

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

Re: [PATCH] core file naming option

[Eli Carter]

Alan Cox wrote:
> 
> > 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).
> 
> 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 `-------------------------------------------------

Re: [PATCH] core file naming option

[n0ano]

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.

On Wed, Sep 26, 2001 at 12:23:50PM -0500, Eli Carter wrote:
> Alan Cox wrote:
> > 
> > > 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).
> > 
> > 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 `-------------------------------------------------
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@indstorage.com
Ph: 303/652-0870x117

Re: [PATCH] core file naming option

[Eli Carter]

n0ano@indstorage.com wrote:
> 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.

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 `-------------------------------------------------

Re: [PATCH] core file naming option

[bill davidsen]

In article <3BB104A9.3AD512A5@inet.com>,
Eli Carter <eli.carter@inet.com> 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 <davidsen@tmr.com>
 "If I were a diplomat, in the best case I'd go hungry.  In the worst
  case, people would die."
		-- Robert Lipe

Re: [PATCH] core file naming option

[Eli Carter]

bill davidsen wrote:
> 
> In article <3BB104A9.3AD512A5@inet.com>,
> Eli Carter <eli.carter@inet.com> 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... ;-)

Thanks.  :)
 
>   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.

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 `-------------------------------------------------

Re: [PATCH] core file naming option

[Phil Edwards]

After seeing this topic in the Kernel Cousin and reading through the mail
archives, I thought I'd mention a very useful feature that Linux could
steal^H^H^H^H^Hleverage from Solaris:  the coreadm(1) program allows users
to set a pattern for core file names, e.g.,

    /var/core/core.%f.%p

for command foo with pid 1234 dumps core in /var/core/core.foo.1234 (to
use the example from the coreadm man page).  There're about half a dozen
% patterns.

The root user can set patterns and policies systemwide (e.g., no coredumps
for regular users, dump all corefiles everywhere into a directory readable
only by root, etc, for security reasons).  Also, this pattern information
is stored per-process AFAICT, so in my login files I have

    coreadm -p core.%f.%p $$

Meaning that all core files go into the current directory.  It gets set
for the shell itself, and all the processes spawned from that shell.

Both as a user and a sysadmin, I've found this to be very very useful.


Anyhow, just a thought.  Thanks for reading.

Luck++;
Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams