All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.