---------- Původní zpráva ----------
Od: Michael Catanzaro <mcatanzaro@gnome.org>
Komu: Discussions about development for the Fedora desktop <desktop@lists.fedoraproject.org>
Datum: 5. 12. 2016 18:51:18
Předmět: Re: Workstation WG call for agenda 2016-Dec-05

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.

ABRT stores the core dump files in /var/spool/abrt and starting with systemd-229, ABRT does

not create the core dump files in CWD because RLIMIT_CORE (ulimit -c) is unlimited by default:

https://github.com/systemd/systemd/blob/master/NEWS#L895

 

> > 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.

ABRT creates stack trace from the dying process rather than from its core dump file.

This approach produces more reliable traces because possibly removed libraries are still

available in memory. It has the benefit that users can turn off saving core dump files

 to disk. This feature has been requested by developers of applications consuming enormous

amounts of memory.

 

> > 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.

Reverting to traditional Linux behavior is a bit challenge with systemd setting RLIMIT_CORE to unlimited.

One must not forget to tell systemd to leave RLIMIT_CORE=0.

> > 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.

Regards,

Jakub