https://bugs.kde.org/show_bug.cgi?id=527902
Bug ID: 527902
Summary: drkonqi-coredump-pickup.service never exits when there
is nothing to pick up; it is killed at RuntimeMaxSec
and left failed after every login
Classification: Applications
Product: drkonqi
Version First 6.7.5
Reported In:
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: minor
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
SUMMARY
On a login where no crash can be picked up (no systemd-coredump journal entry
for the user whose core file still exists), `drkonqi-coredump-processor
--settle-first --pickup --uid <uid>` never exits. It idles in poll() until the
unit's `RuntimeMaxSec=30 minutes`. systemd then stops it, and the user unit
stays `failed` (Result=timeout) for the rest of the session.
STEPS TO REPRODUCE
1. Have no crash with a retained core file for your user. For example,
systemd-tmpfiles has already cleaned up the old core files (the default after a
few days), or there have been no crashes at all.
2. Log in to Plasma.
3. After 30 minutes: `systemctl --user status drkonqi-coredump-pickup.service`
OBSERVED RESULT
```
drkonqi-coredump-pickup.service: Service reached runtime time limit. Stopping.
drkonqi-coredump-pickup.service: Failed with result 'timeout'.
```
While it waits, the process sits in `poll_schedule_timeout` with the journal
files and an inotify watch open. It used 63 ms of CPU in total over the 30
minutes. On this machine there are 17 journal entries matching
`SYSLOG_IDENTIFIER=systemd-coredump COREDUMP_UID=1000`, all of them with their
core file gone, and /var/lib/systemd/coredump/ is empty. It has happened on
every login since the cores were cleaned up. On logins while recent cores still
existed, the processor forwarded them (drkonqi-coredump-launcher@ instances
started) and the unit did not time out.
EXPECTED RESULT
In pickup mode, the processor goes through the existing journal and exits when
it reaches the end, so the unit ends inactive with result success.
ANALYSIS (src/coredump/processor/main.cpp at v6.7.5; the file is identical on
master as of 2026-10-27)
- The only path to quitting is `CoredumpWatcher::finished` ->
`QCoreApplication::quit` (line 176).
- `finished` is emitted only inside the `newDump` handler: after a dump is
forwarded to the launcher (line 172), or when the launcher socket is missing
(line 114).
- In pickup mode, a dump whose core file no longer exists returns early without
emitting `finished` (line 98).
- `CoredumpWatcher` emits `atLogEnd()` once it has drained the journal
(coredumpwatcher.cpp line 110), but main.cpp never connects to it.
So when there are zero pickable dumps, the process waits for new journal
entries indefinitely, and `RuntimeMaxSec` is the only thing that ends it.
SUGGESTED FIX (untested)
Quit at the end of the log in pickup mode only. Per-crash runs, which are not
in pickup mode, keep their current behaviour.
```cpp
if (pickup) {
QObject::connect(&watcher, &CoredumpWatcher::atLogEnd, &app,
&QCoreApplication::quit, Qt::QueuedConnection);
}
```
WORKAROUND
A user drop-in,
`~/.config/systemd/user/drkonqi-coredump-pickup.service.d/override.conf`:
```
[Service]
ExecStart=
ExecStart=/usr/bin/timeout 5m /usr/libexec/drkonqi-coredump-processor
--settle-first --pickup --uid %U
SuccessExitStatus=124
```
With that drop-in, the unit ends at 5:00 with exit 124 and result success. A
crash that can be picked up still exits early.
RELATED
Bug 484864 (fixed in 6.0.4) moved the 60 s `ExecStartPre` sleep into the
process as `--settle-first`. It is a different issue.
SOFTWARE/OS VERSIONS
Fedora Linux 44, KDE Plasma 6.7.5 (Wayland)
plasma-drkonqi 6.7.5, KDE Frameworks 6.31.0, Qt 6.11.2, systemd 259.10, kernel
7.2.12
--
You are receiving this mail because:
You are watching all bug changes.
