On Mon, Dec 05, 2016 at 05:58:19PM -0800, Nicholas Miell wrote: > On 12/05/2016 05:46 PM, Nicholas Miell wrote: > >On 12/05/2016 12:55 PM, Zbigniew Jędrzejewski-Szmek wrote: > >>systemd-coredump+coredumpctl give you pretty easy access to core > >>files, they are just dumped into /var/lib/systemd/coredump/. The > >>advantage is that a) things are logged and can be easily looked up and > >>queried, b) you get a lot of metadata like open files, cgroups, > >>/proc/mountinfo, umask, capability masks, etc., c) a stacktrace is > >>automatically generated and logged locally, d) old coredumps are > >>automatically removed, e) you cannot fill your disk with coredumps. > >> > >>The last two points are crucial for "casual" users, who might want to > >>have easy access to the occasional crash without expending too much > >>attention. > >> > >>Zbyszek > > > >The last two points are solved by setting the soft ulimit to 0, No, they are not. Of course if you set the ulimit to 0, you don't get coredumps, so they don't accumulate. But if you *do* want coredumps, you have to set it to non-zero, and then you're back to square one: if things keep crashing, the kernel will litter your filesystem with coredumps as long as there is space. > >meanwhile systemd-coredump steals away my core dumps and requires > >privileged operations to retrieve them. No, it doesn't. Coredumps are accessible to the user that the program was running under. So you can see your coredumps, and privileges are only required to see coredumps of system programs. And anything else would be a gigantic hole, so I don't think there's an alternative to this. > Also the automatically generated stack traces are wrong. I'd appreciate a bug report on that. Otherwise, it's just trolling. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
