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

[Zbigniew Jędrzejewski-Szmek]

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