On Sun, Dec 04, 2016 at 07:50:18PM -0600, Michael Catanzaro wrote:
On Thu, 2016-12-01 at 18:41 -0500, Paul W. Frields wrote:
- coredumpctl -- mcatanzaro
* Michael did a Change page for F26. Let's make sure we know what the next steps are so it gets picked up by the wrangler/FESCo, and plan developer contact as needed.
Hi,
I've posted the change proposal page at [1].
Nice! I'm obviously biased, but I do think that coredumpctl provides a nice experience when using a machine for development and debugging. Couple of nitpicks:
"coredumpctl" is just a front-end, and systemd-coredump is the thing that actually does the work. The meaning is clear, but strictly speaking, coredumpctl itself cannot be enabled or disabled.
Core dumps will now be stored in the systemd journal
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.
rather than created in the crashing process's current working directory by ABRT
Doesn't abrt store the coredumps in /var/tmp?
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?
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.
Write some program that crashes (e.g. "int main() { ((void(*)())0)(); }"),
That's too much work ;) bash -c 'kill -SEGV $$' works just as well.
Zbyszek