Add more information to coredump related journald etnries

[Jakub Filak]

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.



Yours sincerely,
Jakub Filak
Software Engineer at Red Hat in Brno

[Lennart Poettering]

Post by Jakub Filak
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.
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.

Lennart

[Zbigniew Jędrzejewski-Szmek]

Post by Lennart Poettering

Post by Jakub Filak
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.
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

[Jakub Filak]

Post by Zbigniew Jędrzejewski-Szmek

Post by Lennart Poettering

Post by Jakub Filak
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.
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

[Zbigniew Jędrzejewski-Szmek]

Post by Jakub Filak
My original intention was much less ambitious. I wanted to save the
files in journald fields (_PROC_PID_STATUS, ...) and implement a tool
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).

You can almost do that already with journalct:

journalctl -f -o verbose MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1

will give you such output. A real solution should have something
like systemd-journal-upload, where the last observed cursor is
periodically saved to a file, so that after a restart you don't
iterate over old entries.

Zbyszek