All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Sinz <msinz@wgate.com>
To: "Jakob Østergaard" <jakob@unthought.net>
Cc: Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Core dump file control
Date: Fri, 15 Feb 2002 07:06:45 -0500	[thread overview]
Message-ID: <3C6CF9D5.7417A8F@wgate.com> (raw)
In-Reply-To: <3C6BE18F.7B849129@wgate.com> <20020215124036.C23673@unthought.net>

Jakob Østergaard wrote:
> 
> On Thu, Feb 14, 2002 at 11:10:55AM -0500, Michael Sinz wrote:
> > 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".

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.

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

-- 
Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com
A master's secrets are only as good as
	the master's ability to explain them to others.

  parent reply	other threads:[~2002-02-15 12:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-14 16:10 [PATCH] Core dump file control Michael Sinz
2002-02-15 11:40 ` Jakob Østergaard
2002-02-15 11:44   ` Martin Dalecki
2002-02-15 12:11     ` Michael Sinz
2002-02-15 12:13     ` Jakob Østergaard
2002-02-15 12:22       ` Martin Dalecki
2002-02-15 12:32         ` Jakob Østergaard
2002-02-15 12:55         ` Michael Sinz
2002-02-15 12:06   ` Michael Sinz [this message]
     [not found] <3C6BE18F.7B849129@wgate.com.suse.lists.linux.kernel>
2002-02-14 16:37 ` Andi Kleen
     [not found] ` <363c044a047f1f07d2@[192.168.1.4]>
2002-02-14 17:09   ` Michael Sinz
     [not found] <361c88b8047e6c07d2@[192.168.1.4]>
2002-02-14 17:53 ` Michael Sinz
  -- strict thread matches above, loose matches on Subject: below --
2002-02-15 17:57 Michael Sinz
2002-02-15 19:07 ` Michael Sinz
2002-02-16 17:37 ` Horst von Brand
2002-02-17 14:36   ` Michael Sinz

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=3C6CF9D5.7417A8F@wgate.com \
    --to=msinz@wgate.com \
    --cc=jakob@unthought.net \
    --cc=linux-kernel@vger.kernel.org \
    /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.