From: "Jakob Østergaard" <jakob@unthought.net>
To: Martin Dalecki <dalecki@evision-ventures.com>
Cc: Michael Sinz <msinz@wgate.com>,
Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Core dump file control
Date: Fri, 15 Feb 2002 13:13:20 +0100 [thread overview]
Message-ID: <20020215131320.E23673@unthought.net> (raw)
In-Reply-To: <3C6BE18F.7B849129@wgate.com> <20020215124036.C23673@unthought.net> <3C6CF4AA.8040808@evision-ventures.com>
In-Reply-To: <3C6CF4AA.8040808@evision-ventures.com>; from dalecki@evision-ventures.com on Fri, Feb 15, 2002 at 12:44:42PM +0100
On Fri, Feb 15, 2002 at 12:44:42PM +0100, Martin Dalecki wrote:
> Jakob Østergaard wrote:
...
> >
> >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.
> >
>
> Please execute the size command on the core fiel:
>
> size core
>
> to see why this isn't needed.
>
Huh ?
I suppose you mean, that I can get the name of the executable that caused the
core dump, when running size - right ?
Well, you can do that easier with the file command.
But that doesn't prevent my 7 other processes from overwriting the core file
of the 8'th process which was the first one to crash. Multi-process systems
can, on occation, produce such "domino dumps". Separate names is a *must have*.
And having process names is nicer than having PIDs - I don't mind if my core
files are over-written on subsequent runs, actually it's nice (keeps the disks
from filling up).
--
................................................................
: jakob@unthought.net : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:
next prev parent reply other threads:[~2002-02-15 12:13 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 [this message]
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
[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=20020215131320.E23673@unthought.net \
--to=jakob@unthought.net \
--cc=dalecki@evision-ventures.com \
--cc=linux-kernel@vger.kernel.org \
--cc=msinz@wgate.com \
/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.