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