<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - RFE: Collect Python backtraces" href="https://bugs.freedesktop.org/show_bug.cgi?id=82507#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - RFE: Collect Python backtraces" href="https://bugs.freedesktop.org/show_bug.cgi?id=82507">bug 82507</a> from <a class="email" href="mailto:zbyszek@in.waw.pl" title="Zbigniew Jedrzejewski-Szmek <zbyszek@in.waw.pl>"> Zbigniew Jedrzejewski-Szmek</a> <pre>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. <a href="https://github.com/systemd/systemd/pull/4526">https://github.com/systemd/systemd/pull/4526</a> <a href="https://github.com/keszybz/systemd-coredump-python">https://github.com/keszybz/systemd-coredump-python</a> (In reply to Jakub Filak from <a href="show_bug.cgi?id=82507#c2">comment #2</a>) > 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?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>