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