[systemd-devel] Add more information to coredump related journald etnries

[Jakub Filak]

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.
> 
> 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