** Description changed: - Test Case - --------- - sudo xeyes & - sudo kill -11 $PID from above - receive crash notification - click "Report problem..." - Observe nothing happen + [Impact] + * Users, already annoyed that software has crashed and they have an + unwanted dialog instead, are unable to click the report button to + let us know about the crash. + * Two identical-looking dialogs exist - one on the system-crash + path, and one spawned by the background update-notifier process. + The system crash one is the failing one, the update-notifier one + is fine. The system crash one shows first, and users may not + bother to approve the second one given that the first didn't do + anything + * We receive fewer crash reports - Research - -------- - crash.c calls the following '/usr/bin/pkexec /usr/share/apport/apport-gtk' and this works if I call it manually so something must be awry in crash.c. + [Test Plan] + * sudo xeyes & + * sudo kill -11 $PID from above + * receive crash notification + * click "Report problem..." + * We should see the report procedure start - ProblemType: Bug - DistroRelease: Ubuntu 19.04 - Package: update-notifier 3.192.14 - ProcVersionSignature: Ubuntu 5.0.0-7.8-generic 5.0.0 - Uname: Linux 5.0.0-7-generic x86_64 - NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair - ApportVersion: 2.20.10-0ubuntu23 - Architecture: amd64 - CurrentDesktop: MATE - Date: Fri Mar 22 13:46:38 2019 - InstallationDate: Installed on 2018-08-10 (223 days ago) - InstallationMedia: Ubuntu-Server 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) - SourcePackage: update-notifier - UpgradeStatus: Upgraded to disco on 2019-02-28 (21 days ago) + [Where problems could occur] + * By the nature of the supplied fix, if the report process hangs + around, the normal systemd cleanup procedures would fail to clean + it up. This same risk is present for report processes initiated + on the non-system-crash report code path. + * Wayland is still affected even with this fix, for different reasons + (LP: #1947929) + + [Other Info] + Q: Systemd says KillMode=process is not recommended + https://www.freedesktop.org/software/systemd/man/systemd.kill.html + + In this case, killing the other processes in the control-group is part + of the problem. + + The system crash dialog is a relatively simple bit of code that shows + a dialog, then runs a report process. This dialog process is spawned + as part of a chain of processes downstream from + update-notifier-crash.service. + + This dialog runs the report process using g_spawn_async(). After + spawning the report process, there isn't any particular reason to keep + the dialog process around, so it exits. This exit is triggering the + KillMode behavior, and because the report process is in the control + group, the report process is killed. + + Another possibility for addressing the process management is to run + the report process synchronously - keep the dialog process around + until the report is done and just make the dialog not visible. This + is not a workable answer in this case because with the current gtk + code usage, the dialog sticks around - even after the call to + gtk_widget_destroy()! This appears to be due to usage of + gtk_dialog_run(). Long term I recommend we modernize this code. + My initial fix for this LP was in that direction. + https://git.launchpad.net/~dbungert/update-notifier/commit/?id=06058d5705ed7cd636206c1ee72c376ec903fe74
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1821412 Title: "System program problem" report button does nothing To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1821412/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
