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. 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. 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. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel