s_frueau@ira.uka.de (Thorsten Frueauf) writes:

>At first look, this may sound nice, but note that with this approach
>there can be only _one_ core per programm - and that in a multi user
>envirement.

Obviously, the code in the PR was only a proof of concept.  For one, it
would have to be a config option.

Note also, that this is not any different from the case where a daemon
dumps core multiple times.  You get only the last core dump for each
working directory.

>So if two people develop programm foo - both at different
>points, but both dump core, one might not be able too.

This option is not intended for development machines but rather for
production machines.  I can think of a number of reasons why I would
want to collect core dumps in a common directory for certain machines.

>Thus with your change you would have to change the naming scheme too.

So what?  Just include the pid or the date in the filename too.
It's just a trivial code change.

>But then you may not be able to know which program actually dumped
>core either - just think about different versions of one program
>installed.

Huh?


Come to think of it, it would be really nice, if I could specify the
location and filename format for the core dumps in the environment,
so that it gets inherited by the child processes.

Something like
	setenv COREDUMPNAME /whereever/%n.%t.%p.core

Where %n == program name, %p == pid and %t current time.
The default, if COREDUMPNAME wasn't set, would be "./%n.core".
And the default should probably be settable via sysctl.

Heiko?

-- 
Christoph Badura

Now available in print: Lion's Commentary on UNIX 6th Edition, with Source Code
			http://www.peer-to-peer.com/