On Mon, 2016-12-05 at 17:03 +0000, Zbigniew Jędrzejewski-Szmek wrote:
That's misleading. Current behaviour of systemd-coredump is to
store
the metadata in the journal, and the coredump on disk. Storing it in
the journal was rather inefficient, and we backed away from this. I
think saying "Core dumps will be processed by systemd-coredump and
information about core dumps will be stored in the journal" or
something along those lines would be better.
OK, I revised the change page to reflect this.
> rather than created in the crashing process's current
working
> directory by ABRT
Doesn't abrt store the coredumps in /var/tmp?
If you set ulimit it creates the core dumps in cwd. At least it did in
F23; it's probably broken in F24 due to SELinux or systemd or something
or other, but creating core dumps in cwd is definitely the previous and
intended Fedora behavior.
> Notably, crash-time stacktraces will no longer be available
Can you explain this a bit more? systemd-coredump generates stack
traces
at crash time. Is something missing from them?
I do not know. It's not essential for the change page, so I'll just
remove it for now, unless somebody else chimes in.
> Developers who prefer to manually work with core dumps will
still
> be
> able to revert to the previous behavior.
Previous behaviour would be abrt handling core dumps.
Yup, or you can revert to traditional Linux behavior too... choice etc.
> Write some program that crashes (e.g. "int main() {
> ((void(*)())0)(); }"),
That's too much work ;) bash -c 'kill -SEGV $$' works just as well.
Yeah, that's better indeed.
Michael