[systemd-bugs] [Bug 82507] RFE: Collect Python backtraces

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=82507

--- Comment #3 from Zbigniew Jedrzejewski-Szmek <zbyszek at in.waw.pl> ---
So... I had a look at this today. I made a POC implementation based on
abrt_exception_handler that sends the backtrace to systemd-coredump, which
attaches additional metadata and sends the whole thing to systemd-journald.
It's simple enough and should work in general.

https://github.com/systemd/systemd/pull/4526
https://github.com/keszybz/systemd-coredump-python

(In reply to Jakub Filak from comment #2)
> If you want to show detected uncaught Python exceptions in coredumpctl, why
> don't you teach coredumpctl to load that data from Problems2 D-Bus API[1]
> exposed by ABRT? Once you do that, coredumpctl would be able to show also
> uncaught Java exceptions, Ruby exceptions and basically everything ABRT
> detects. There is no need to re-invent/re-implement the error detection
> utilities.
I definitely do not want to reinvent the wheel. Instead we should build on
existing tools as much as possible. Of the two options, the one below appeals
much more to me. coredumpctl is a low level tool that lists and extracts
coredump entries in the journal. I don't think it should become a client to
abrt, which feels like a higher level tool. I'd rather prefer for abrt to build
on the base functionality provided by systemd-coredump.

> Or if you don't want to use the D-Bus API, why don't you ask ABRT team to
> write the detected exception data to journal too? We are working on it
> [2][3] because Cockpit team asked us for it.
Yes, something like this. I'm experimenting with the systemd-coredump-python
because this works without abrt running. So it has the same basic advantages
and disadvantages that systemd-coredump has over abrt: does not require abrt to
be running, works in early boot, only logs to the journal and does not provide
any higher-level handling.

I think such a module might be integrated one of three ways:
- an alternative to the abrt hook, to be used when abrt-addon-python3 is not
installed
- an alternative to the abrt hook, to be used until abrt becomes available
- teaching abrt to read python backtraces from the journal

The last option is the most interesting I think, but it only makes sense if
abrt gets the general ability to read coredump entries from the journal in
general, also for actual coredumps.

The changes in #4526 are fairly generic, and should allow taking the same path
for other languages (ruby, java, etc.). What d'ya think?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-bugs/attachments/20161031/30f58a95/attachment.html>