Subject: Re: core dump filename format
To: Andrew Brown <atatat@atatdot.net>
From: Gandhi woulda smacked you <greywolf@starwolf.com>
List: tech-userlevel
Date: 09/10/1999 10:45:22
On Wed, 8 Sep 1999, Andrew Brown wrote:

# and also from capital formats.  printf(3) doesn't have too many of
# these and half of them (afaict) are "deprecated".  one more point...i
# think the "format" part of the %thing shoudl be between the % and the
# thing.  if you put it after, it makes it hard to use those characters
# in those spots literally.

Has anyone given any thought to these files not being named something
that resembles [^s]*core*?  What happens to the nightly system check
that goes out and looks for core files?  You want to run 'file' on
every single file on your disk and have it report back on that?  That's
ludicrous.

If there is no core format set, the default should be %n.core;
obviously gcore is going to produce %p.core.  Whatever format
you choose, ".core" should be appended to it.  This makes it
a bit more difficult to achieve a file named "core", but we're
obviously making a tradeoff here.

Has it also occurred that the message (core dumped) may prove
a mite confusing to a willing-to-learn neophyte (as we all were
once) whose sysadmin has set the core format to "/cores/%u/%n.%p"?
We'd have to go back and change all the shells/progs which tell you
that a core is dumped to tell you *where* it left the core file.

...at least if my core file didn't end up in "./core" or "./%n.core",
I would like to know where it *did* go!

Theory of least surprise and all that.

# as for the comments on putting it in sysctl/rlimits or in a "user-
# settable sysctl base", i'd opt for the latter, if at all possible.
# then, with an established per-user/process sysctl area (with
# inheritance ala rlimit), the way would be paved for something like
# access control on system calls for individual processes.

This apparently exists already: you don't think user.cs_path is per-user,
do you?

And on another tangerine, shouldn't the user.* sysctl variables really
be called something else since they're not really on a per-user basis,
but a per-process basis?

or am I rambling too much to be intelligible, here?

				--*greywolf;
--
Microsoft:
	"Just click on the START button and your journey to the Dark Side
	 will be complete!"