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