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
_______________________________________________
desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
