On Fri, 2014-09-05 at 19:06 +0200, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Sep 05, 2014 at 06:35:19PM +0200, Lennart Poettering wrote: > > On Fri, 05.09.14 01:40, Jakub Filak (jfi...@redhat.com) wrote: > > > > > Hello systemd, > > > > > > I’m a ABRT developer and I’d like to replace ABRT’s coredumper with > > > systemd-coredump and read coredumps from systemd-journal. In order > > > to achieve my goal, I need to extend the set of captured > > > /proc/$PID/[files] > > > by systemd-coredump, because we attach those files in Bugzilla bugs. > > > > > > Files from /proc/PID needed by ABRT: > > > status > > > maps > > > limits > > > cgroup > > > open_fds > > > environ > > > cmdline > > > cwd > > > rootdir > > > > > > > > > Do you have any objections to my plan or hints to achieve my goal? > > > I’d be grateful for any feedback you may have. > > > > Sounds like good things to add, happy to take a patch. the cmdline and > > cgroup we already have (at least in the journal, not on the coredump > > files though -- where we only attach the stuff we get racefreely > > passed in from the kernel, not the stuff we have to read from /proc, > > potentially racefully, at least currently). Attaching all data on the > > coredumps as xattrs should be conceptually OK, but this might not end > > up working due to size limits on xattr imposed by ext4? if the "maps" > > for example might grow large we might not be able to use xattrs to > > store this in. If we cannot store this in xattrs I think we should > > prefer to not invent another storage but simply query the journal for > > the additional metdata. > > I think it is preferable to query the journal always and use is the > primary source of information, rather than enumerating files in > /var/lib/systemd/coredump/. The journal might contain information > about more dumped cores, since a) the user might disable saving cores > to /var/lib/systemd/coredump/, b) some core might be too large to > save, c) there might not be enough disk space. In any of those cases, > the journal might contain a useful traceback that we generated > on-the-fly. I'd prefer to work with abrtd developers to make this > information contain everything they need, rather than doing the > reverse and starting with the core and going back to the journal to > find missing information. > > Zbyszek
Lennart, Zbyszek, Thank you for your quick replies! My original intention was much less ambitious. I wanted to save the files in journald fields (_PROC_PID_STATUS, ...) and implement a tool based on Examples at: http://www.freedesktop.org/software/systemd/man/sd_journal_get_fd.html In the first version, the tool would wait for a new coredump and create same data directory as ABRT's coredumper (copy the journald message to disk). Jakub _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
