Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#41286 - [systemd] coredump handling

Attached to Project: Arch Linux
Opened by Hussam Al-Tayeb (hussam) - Monday, 21 July 2014, 12:20 GMT
Last edited by Dave Reisner (falconindy) - Monday, 21 July 2014, 12:27 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Right now, you guys remove the coredump rule:

# remove the coredump rule until minidumps are a thing.
rm "$pkgdir/usr/lib/sysctl.d/50-coredump.conf"

This basically removes a functionality probably don't want.
But if they do, they will have to install that file in /etc/sysctl.d/

As of systemd 215, the situation is a lot better as coredumps are stored in /var/lib/system/coredumps/ by default instead of polluting the journal.

If you still want your users' systems to not collect coredumps,
how about instead just modify the stock /etc/systemd/coredump.conf to

[Coredump]
Storage=none

This way users can modify coredump.conf if they want coredumps stored instead of having to add an additional file in /etc/sysctl.d/

This sounds a bit more elegant. Do think about it please :)

The advantage of reinstating that file but defaulting Storage to none is that the stack traces under systemd 215 are logged but the coredump isn't. So even with Storage set to none, i will at least be able to know what crashed and when.

Thank you for reading the report.
This task depends upon

Closed by  Dave Reisner (falconindy)
Monday, 21 July 2014, 12:27 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#41167 

Loading...