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