[systemd-devel] Add more information to coredump related journald etnries
jfilak at redhat.com
Tue Sep 9 07:55:39 UTC 2014
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 (jfilak at 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.
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:
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
More information about the Crash-catcher