https://bugs.kde.org/show_bug.cgi?id=439279
Harald Sitter <sit...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sit...@kde.org
Status|REPORTED |RESOLVED
Resolution|--- |DOWNSTREAM
--- Comment #1 from Harald Sitter <sit...@kde.org> ---
>From your description and the fact that you are on fedora I'm guessing that
this happened because fedora uses experimental systemd service startup to
manage the session. The caveat there is that the drkonqi process is part of the
unit that crashed, which then means that if systemd decides to restart the unit
(which it will when crashed) it will forcefully terminate drkonqi because it
cleans up the previous processes spawned by the unit.
For 5.22 there's nothing we can do about that. In 5.23 there's a new coredumpd
based post-mortem system where drkonqi doesn't actually directly relate to the
process that crashed, but the process terminates, its memory gets recorded by
systemd's coredumpd and then we start drkonqi from there to debug the dumped
process rather than the live process (that eventually gets killed by systemd).
The thing is, as far as I am aware fedora is using ABRT instead of coredumpd to
handle these crashes, so practically speaking fedora probably shouldn't be
shipping/enabling drkonqi at all but use ABRT. Certainly not in 5.22 because of
the described problem. The latest kcrash sports an environment option
KCRASH_DUMP_ONLY=1 for that. When set drkonqi is not started by the crashing
application but the app will dump its core, invoking the global core handler
(supposedly ABRT) and everything else happens there. You may want to bring this
to fedora's attention.
--
You are receiving this mail because:
You are watching all bug changes.
