systemd-coredump in distros

Andreas Arnez <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <[email protected]>
It seems common for new distros to install systemd-coredump by default
and disable core files in the current working directory.  For instance,
see the announcement "Enable systemd-coredump by default" for Fedora 26
(https://fedoraproject.org/wiki/Changes/coredumpctl).

Is there a recommended/preferred way to deal with this in a typical
development use case?  I stumbled upon some issues with systemd-coredump
and don't know if I misunderstood something:

* In my tests, after invoking a command that dumps core, it could happen
  that "coredumpctl" failed immediately afterwards and succeeded a
  second later -- maybe due to asynchronous processing?

* There does not seem to be a way for a user to remove core dumps from
  the journal.  Thus a developer's experiment may pile up dumps in the
  journal, occupying lots of space and making the dumps more difficult
  to find.

* I've seen dumps (from GDB's bigcore.exp) being truncated by
  coredumpctl down to four Gigabytes, although no such limit was set in
  /etc/systemd/coredump.conf.  Note that I haven't investigated where
  the truncation happens.

Considering these issues I wonder whether there's a way for a user to
tell systemd-coredump something like: "Core dumps from this process
should be treated traditionally and written to its current working
directory".  Is that possible?  If not, should it be?

--
Andreas
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.