On 05/13/2016 01:05 AM, Michael Catanzaro wrote:
On Thu, 2016-05-12 at 23:26 +0100, Peter Robinson wrote:
Yet further up in the thread there are people saying that it's not suitable for outside of developers.
It's not suitable for non-developers in the sense that no command line program is ever suitable for nontechnical users, but it's not somehow inappropriate to have enabled on all systems. It's a tool that makes debugging and bug reporting easier, but it's not a distro bug reporting tool. ABRT remains our distro bug reporting tool.
Basically: if you want to work with core dumps, you probably want to use coredumpctl (though understandably the ABRT folks prefer abrt-cli). If not, you don't care. Status quo is that we have coredumpctl installed and broken by default.
Michael
Well, if I need to analyze core dump files during development I prefer no intermediate tool - no ABRT, no systemd-coredump. I just set 'ulimit -c unlimited' and run gdb on the file generated in CWD. Actually, that's not true, I run my programs in gdb, so I don't need to analyze local core dump files most of the time. I usually need to analyze core dump files generated on foreign systems.
One benefit of ABRT for some developers was that it could create the old way core dump files in CWD but starting with systemd-229 we had to disable this feature by default. Because systemd changed the default RLIMIT_CORE from 0 to unlimited ('ulimit -c').
I do prefer abrt-cli (or abrt - which can run gdb too) when I need to work with errors/crashes/problems of any source - Python, Java, C/C++, Kernel oops, Ruby, etc. I can analyze them and eventually report them.
systedm-coredump makes ABRT's job harder. Currently, ABRT fails to get core dump files from systemd-journal because systemd-coredump switched from xz compression to lz4 compression. My bad, I should have been watching systemd development.
Best regards, Jakub ABRT folk