On Fri, Jun 20, 2014 at 08:02:54PM +0200, Lennart Poettering wrote: > On Tue, 14.05.13 19:09, Oleksii Shevchuk (alx...@gmail.com) wrote: > > Heya! > > Sorry for resurrecting this thread from last year. I never found the > time to merge this, but I finally had a closer look and then sat down > and tried to isolate out of it what I liked and what I didn't. I > commited different patches for this though. Sorry for the looooong > delay! > > So here's what is implemented in git now: > > a) There's a configuration file /etc/systemd/coredump.conf with some of > the options you proposed. > > b) We will now store coredumps outside of the journal by default, but > you can also place them in the journal only, or at both places. > > c) I hooked this thing up with elfutils' libdw, which gives us pretty, > native backtraces in the journal now, without involving gdb or > anything like that. Only a minimal (optional) dependency on libdw to > get them. And the best thing is that elfutils is actually maintained > and can read debuginfo files, unlike some other options for stuff > like this (like libunwind). > > d) I hooked this up with ACLs so that a user can read but not change his > own coredumps stored in /var.
This all sounds great. > What I didn't take: > > 1) the API to specify external programs for compressing or processing > the coredumps. I am really not too fond of doing things with invokign > external programs. THat's always chickening out in my eyes, avoiding > to solve the problems properly. By using elfutils' libdw we get the > backtrace feature nicely integrated now without invoking external > programs, I guess the need for PreprocessJournal= is hence redundant > with that. There's no support for compression though, but I'd be fine > with taking a simple patch for that that directly speaks to the xz > APIs. After all we link against the xz already. Of course this would > need support in both the coredump hook to transparently compress the > coredumps and in coredumpctl on the client side so that "coredumpctl > gdb" just works without manual decompression. > > 2) I change the paths to store this in. I drop the coredumps in > /var/lib/systemd/coredump/ now. While the journal logs appear to be > something worth sharing across the network as "logs"; I am not > convinced that the coredumps would fit that category. The fact that this path is hardcoded is kind of lousy. See below... > Anyway, I hope this makes sense. > > With these changes coredumpctl actually is now really useful and just > works. I have thus dropped the "systemd-" prefix. We should probably > start advertising it more. Are there plans to limit the size of the directory in any way? As is, the default setup is prone to a simple DoS attack as a non-root user: while true; do bash -c 'kill -SEGV $$'; done Cheers, Dave _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
