Public bug reported:
[ Impact ]
* On systems where the user has deliberately disabled crash uploads
(whoopsie.path disabled, whoopsie.service inactive), the Kubuntu
notifier still runs data/whoopsie-upload-all when a crash is detected.
The helper exits 1 with "ERROR: whoopsie is not running", leaving a
failed transient user unit each time. Repeated crashes accumulate
failed units, and systemctl --failed / monitoring tools report a
fault although the system is configured as the user intended.
* The helper should treat an explicit opt-out as "nothing to do" and exit 0.
A genuine failure (whoopsie enabled but not running) must still be an error.
[ Test Plan ]
Do not upload real crash reports during testing.
1. Install kubuntu-notification-helper 26.04ubuntu6 on Kubuntu 26.04.
2. Opt out of crash reporting:
sudo systemctl disable --now whoopsie.path whoopsie.service
systemctl is-enabled whoopsie.path # -> disabled
pidof whoopsie # -> no output, exit 1
3. As the desktop user, run:
/usr/share/kubuntu-notification-helper/whoopsie-upload-all (installed
path may differ; check dpkg -L)
echo $?
Before the fix: stderr "ERROR: whoopsie is not running", exit 1.
After the fix: stdout "INFO: whoopsie.path disabled; skipping automatic
upload", exit 0.
4. Trigger a crash notification (e.g. kill -SEGV a test KDE app with
apport enabled) and confirm:
systemctl --user --failed
lists no failed whoopsie-upload-all transient unit after the fix
(it lists one per crash before the fix).
5. Regression, enabled but not running:
sudo systemctl enable whoopsie.path; sudo systemctl stop whoopsie.path
whoopsie.service
Running the helper still prints "ERROR: whoopsie is not running"
and exits 1.
6. Regression, whoopsie running:
sudo systemctl start whoopsie.service
The helper proceeds to collect_info() as before.
[ Where problems could occur ]
* The change only adds a branch on the path where whoopsie is already
not running; the running-daemon path is untouched.
* If systemctl is unavailable or fails, stdout is empty, so the helper
falls through to the old error/exit 1 behaviour.
* A masked whoopsie.path is also treated as an opt-out ("masked" is
reported by is-enabled); this goes slightly beyond the reporter's
patch (disabled only).
* Other is-enabled states (static, indirect, alias) keep the old error
behaviour.
* Risk: a crash on a system with whoopsie.path disabled is now silently
skipped instead of reported as failed; this is the intended behaviour.
* Alternative (not implemented): gate the launch in
ApportEvent::batchUploadAllowed() in the C++ daemon. It would avoid
spawning the helper at all, but needs a larger change and a rebuild/test
of the daemon.
** Affects: kubuntu-notification-helper (Ubuntu)
Importance: Medium
Assignee: Erich Eickmeyer (eeickmeyer)
Status: Fix Committed
** Affects: kubuntu-notification-helper (Ubuntu Resolute)
Importance: High
Assignee: Erich Eickmeyer (eeickmeyer)
Status: In Progress
** Affects: kubuntu-notification-helper (Ubuntu Stonking)
Importance: High
Assignee: Erich Eickmeyer (eeickmeyer)
Status: In Progress
** Affects: kubuntu-notification-helper (Ubuntu Tenacious)
Importance: Medium
Assignee: Erich Eickmeyer (eeickmeyer)
Status: Fix Committed
** Changed in: kubuntu-notification-helper (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2172769
Title:
[SRU] whoopsie-upload-all fails with "whoopsie is not running" when
whoopsie.path is disabled
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kubuntu-notification-helper/+bug/2172769/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
