Subject: Re: kern/4099: Gather coredumps in one place
To: None <current-users@NetBSD.ORG>
From: Christoph Badura <firstname.lastname@example.org>
Date: 09/08/1997 22:05:27
email@example.com (Heiko W.Rupp) writes:
>Christoph Badura wrote:
>|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.
>But then, you won't eliminate the find and make automatic removal even
No, not necessarily. But that's not the point. You provided some
sample code that implements a new *policy* for core dumps. I merely
took that idea and developed into a more general facility for specifying
core dump policy by the administrator. The code that implements both
proposals should be quite small and can be made a compile time option
in any case.
If you're changing the core dump policy, why not go for the whole hog?
Especially when the additional code will be rather simple and small.
I sure could put the more flexible implementation to good use. Say, give
news processes their own core dump directory and leave the other users
>I don't really like that, but why not. Setting the directory via
>sysctl is in every case superior to defining it at compile time.
I meant, setting it with a compile time option and overriding it
with sysctl. The first comes essentially for free.
>You will at least have some unique pattern in the name (that the
>kernel should probably add) to make automatic removal possible. Users
>tend to waste much disk space by not removing core dumps.
That is an actual policy and the system administrator should
decide what the local policy is.
Now available in print: Lion's Commentary on UNIX 6th Edition, with Source Code