[Bug 1821412] Re: "System program problem" report button does nothing

Thu Oct 28 22:16:46 UTC 2021

** 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
Foundations Bugs, which is subscribed to update-notifier in Ubuntu.
https://bugs.launchpad.net/bugs/1821412

Title:
  "System program problem" report button does nothing

Status in update-notifier package in Ubuntu:
  In Progress
Status in update-notifier source package in Bionic:
  New
Status in update-notifier source package in Focal:
  New
Status in update-notifier source package in Hirsute:
  New
Status in update-notifier source package in Impish:
  New

Bug description:
  [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

  [Test Plan]
    * sudo xeyes &
    * sudo kill -11 $PID from above
    * receive crash notification
    * click "Report problem..."
    * We should see the report procedure start

  [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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1821412/+subscriptions