linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Sinz <msinz@wgate.com>
To: Bill Davidsen <davidsen@tmr.com>,
	marcelo@conectiva.com.br,
	Linux Kernel List <linux-kernel@vger.kernel.org>,
	akpm@digeo.com, riel@conectiva.com.br,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	rml@tech9.net
Subject: Re: [PATCH] kernel 2.4.19 & 2.5.38 - coredump sysctl
Date: Mon, 23 Sep 2002 15:00:10 -0400	[thread overview]
Message-ID: <3D8F64BA.4010005@wgate.com> (raw)
In-Reply-To: Pine.LNX.3.96.1020922145444.7597A-100000@gatekeeper.tmr.com

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.



  parent reply	other threads:[~2002-09-23 18:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-20 20:40 [PATCH] kernel 2.4.19 & 2.5.38 - coredump sysctl Michael Sinz
2002-09-20 20:59 ` Andrew Morton
2002-09-20 21:01 ` Andrew Morton
2002-09-20 21:29   ` Michael Sinz
2002-09-20 21:50     ` Andrew Morton
2002-09-20 21:53     ` Andrew Morton
2002-09-20 23:32       ` Michael Sinz
2002-09-22 19:02   ` Bill Davidsen
2002-09-22 23:59     ` Andrew Morton
2002-09-23 19:00     ` Michael Sinz [this message]
     [not found] <3D8B87C7.7040106@wgate.com.suse.lists.linux.kernel>
     [not found] ` <3D8B8CAB.103C6CB8@digeo.com.suse.lists.linux.kernel>
     [not found]   ` <3D8B934A.1060900@wgate.com.suse.lists.linux.kernel>
     [not found]     ` <3D8B982A.2ABAA64C@digeo.com.suse.lists.linux.kernel>
2002-09-20 23:12       ` Andi Kleen
2002-09-20 23:27         ` Andrew Morton
2002-09-20 23:47           ` Andi Kleen
2002-09-21 20:19             ` Francois Romieu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D8F64BA.4010005@wgate.com \
    --to=msinz@wgate.com \
    --cc=akpm@digeo.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davidsen@tmr.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=riel@conectiva.com.br \
    --cc=rml@tech9.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).