Re: Change userland core dump location
Stuart Henderson wrote:
> On 2023-09-13, Eric Wong wrote:
> > Theo de Raadt wrote:
> >> There isn't a way. And I will argue there shouldn't be a way to do that.
> >> I don't see a need to invent such a scheme for one user, when half a
> >> century
> >> of Unix has no way to do this.
> >> Sorry.
> >
> > I have a different use case than Johannes but looking for a similar feature.
> > Maybe I can convince you :>
> >
> > For background, I develop multi-process daemons and OpenBSD is
> > the only platform I'm noticing segfaults on[1].
> >
> > The lack of PIDs in the core filenames means they can get
> > clobbered in parallel scenarios and I lose useful information.
> >
> > Sometimes, daemons run in / (or another unwritable directory);
> > and the core dump can't get written, at all.
>
> If the daemons are changing uid, read about kern.nosuidcoredump
> in sysctl(8) (set the sysctl, mkdir /var/crash/progname, and
> it will write to $pid.core).
They aren't, they're all per-user. I'm seeing core files from a
heavily-parallelized test suite[1]. Some processes can chdir to
/, some stay in their current dir, and some chdir into
short-lived temporary directories.
Thanks.
[1] The good news is the test suite passes; but the lone core dump
sometimes get tells me it's in the Perl destructor sequence.
I've been adding `END {}' blocks and explicit undefs but still
occasionally see a perl.core file after a run. And even if
I don't see that file after a run, I wouldn't know if a core
dump failed in / or a temporary directory.
Re: Change userland core dump location
On 2023-09-13, Eric Wong wrote: > Theo de Raadt wrote: >> There isn't a way. And I will argue there shouldn't be a way to do that. >> I don't see a need to invent such a scheme for one user, when half a century >> of Unix has no way to do this. >> Sorry. > > I have a different use case than Johannes but looking for a similar feature. > Maybe I can convince you :> > > For background, I develop multi-process daemons and OpenBSD is > the only platform I'm noticing segfaults on[1]. > > The lack of PIDs in the core filenames means they can get > clobbered in parallel scenarios and I lose useful information. > > Sometimes, daemons run in / (or another unwritable directory); > and the core dump can't get written, at all. If the daemons are changing uid, read about kern.nosuidcoredump in sysctl(8) (set the sysctl, mkdir /var/crash/progname, and it will write to $pid.core). -- Please keep replies on the mailing list.
Re: Change userland core dump location
Theo de Raadt wrote:
> There isn't a way. And I will argue there shouldn't be a way to do that.
> I don't see a need to invent such a scheme for one user, when half a century
> of Unix has no way to do this.
> Sorry.
I have a different use case than Johannes but looking for a similar feature.
Maybe I can convince you :>
For background, I develop multi-process daemons and OpenBSD is
the only platform I'm noticing segfaults on[1].
The lack of PIDs in the core filenames means they can get
clobbered in parallel scenarios and I lose useful information.
Sometimes, daemons run in / (or another unwritable directory);
and the core dump can't get written, at all.
On Linux, I've set sys.kernel.core_pattern=/var/tmp/core and
sys.kernel.core_uses_pid=core_uses_pid[2] since the early 2000s
or so to minimize my chance of losing important core dumps.
Thanks for reading.
[1] something in Perl / DBD::SQLite destruction order; not sure
if it's down to the versions of the software packaged for
OpenBSD or something else. I haven't seen it on Linux nor FreeBSD;
but yeah, Perl destruction with interelated XS objects graphs
get tricky...
[2] Nowadays, Linux core_pattern supports printf-like formats,
but I've been relying on it for longer.
> Johannes Thyssen Tishman wrote:
>
> > Hi everyone,
> >
> > is there a way to configure a location to store userland core dumps?
> > I'd like to store them in /tmp to keep them available only until
> > the next reboot. This way I can avoid having core dumps, that
> > sometimes I don't even know about, scattered all over my home
> > directory.
> >
> > I've read about 'sysctl kern.nosuidcoredump' in sysctl(8), but I
> > believe files stored under /var/crash/${program} are persistent
> > after reboots, right? Also, I know I can disable them from
> > /etc/login.conf, but I'd prefer to keep them at least until the
> > next reboot just in case.
> >
> > I'm sure that there must be a reason for why OpenBSD defaults to
> > dumping core files like it does, so please let me know if what I'm
> > asking is a bad idea. I would really appreciate it.
> >
> > Thank you.
> >
> > Kind regards,
> > Johannes
> >
Re: Change userland core dump location
Hi Paul, > Or in your user's crontab: > @reboot /usr/bin/find ~ -fstype local -name '*.core' -delete This is a great alternative, thank you very much. Kind regards, Johannes
Re: Change userland core dump location
Hi Theo,
I understand. I'll learn to live with it. Thank you anyways.
Kind regards,
Johannes
Aug 25, 2023 16:54:32 Theo de Raadt :
> There isn't a way. And I will argue there shouldn't be a way to do that.
> I don't see a need to invent such a scheme for one user, when half a century
> of Unix has no way to do this.
> Sorry.
>
> Johannes Thyssen Tishman wrote:
>
>> Hi everyone,
>>
>> is there a way to configure a location to store userland core dumps?
>> I'd like to store them in /tmp to keep them available only until
>> the next reboot. This way I can avoid having core dumps, that
>> sometimes I don't even know about, scattered all over my home
>> directory.
>>
>> I've read about 'sysctl kern.nosuidcoredump' in sysctl(8), but I
>> believe files stored under /var/crash/${program} are persistent
>> after reboots, right? Also, I know I can disable them from
>> /etc/login.conf, but I'd prefer to keep them at least until the
>> next reboot just in case.
>>
>> I'm sure that there must be a reason for why OpenBSD defaults to
>> dumping core files like it does, so please let me know if what I'm
>> asking is a bad idea. I would really appreciate it.
>>
>> Thank you.
>>
>> Kind regards,
>> Johannes
>>
Re: Change userland core dump location
There isn't a way. And I will argue there shouldn't be a way to do that.
I don't see a need to invent such a scheme for one user, when half a century
of Unix has no way to do this.
Sorry.
Johannes Thyssen Tishman wrote:
> Hi everyone,
>
> is there a way to configure a location to store userland core dumps?
> I'd like to store them in /tmp to keep them available only until
> the next reboot. This way I can avoid having core dumps, that
> sometimes I don't even know about, scattered all over my home
> directory.
>
> I've read about 'sysctl kern.nosuidcoredump' in sysctl(8), but I
> believe files stored under /var/crash/${program} are persistent
> after reboots, right? Also, I know I can disable them from
> /etc/login.conf, but I'd prefer to keep them at least until the
> next reboot just in case.
>
> I'm sure that there must be a reason for why OpenBSD defaults to
> dumping core files like it does, so please let me know if what I'm
> asking is a bad idea. I would really appreciate it.
>
> Thank you.
>
> Kind regards,
> Johannes
>
Change userland core dump location
Hi everyone,
is there a way to configure a location to store userland core dumps?
I'd like to store them in /tmp to keep them available only until
the next reboot. This way I can avoid having core dumps, that
sometimes I don't even know about, scattered all over my home
directory.
I've read about 'sysctl kern.nosuidcoredump' in sysctl(8), but I
believe files stored under /var/crash/${program} are persistent
after reboots, right? Also, I know I can disable them from
/etc/login.conf, but I'd prefer to keep them at least until the
next reboot just in case.
I'm sure that there must be a reason for why OpenBSD defaults to
dumping core files like it does, so please let me know if what I'm
asking is a bad idea. I would really appreciate it.
Thank you.
Kind regards,
Johannes
