[Bug 2120731] [NEW] Raspberry Pi 5 16G, Ubuntu 24.04: pemmican-reset waits for notification acknowledgement, prevents full desktop service startup

[Kevin Brown]

Public bug reported:

When pemmican-reset starts and finds that the power supply is
insufficient, it issues a notification.  This is all well and good.  But
the way it does so is to *wait for the notification to be acknowledged*
before it exits.  That is *not* all well and good, because in doing so
it prevents systemd user services such as graphical-session from
starting.  And this is so because it specifies in its systemd service
description:

```
[Install]
WantedBy=graphical-session.target
```

The end result is that if it issues a notification, the graphical
session service will hang waiting for it to complete until the user
explicitly acknowledges the notification.  This, in turn, causes xdg-
desktop-portal to fail to start, and that causes gnome-terminal-service
to fail to start because it waits for the identifier supplied by xdg-
desktop-portal to become available via dbus.  And as a consequence, you
can't start gnome-terminal until you clear the notification (and perhaps
not even then, since these other service startups might well have timed
out by the time the notification is acknowledged).

This is a serious bug.  Ubuntu users on Pi5 systems that have power
supplies that would result in this notification will *all* be affected
by this in various ways, depending on what user services need to be up
and running for them to do what they do.


The bottom line is this: pemmican-reset *must not* block in such a way
as to prevent anything else from starting.  Its systemd descriptor says
that it's a one-shot startup:

```
[Service]
Slice=session.slice
Type=oneshot
ExecStart=pemmican-reset
Restart=on-failure
RestartSec=1s
```

which means that systemd will wait for it to exit.

I worked around this issue by supplying my own augmentation to the
pemmican-reset systemd descriptor:

```
# /etc/systemd/user/pemmican-reset.service.d/fix-deps.conf
[Unit]
After=graphical-session.target

[Install]
WantedBy=default.target
```

While pemmican-reset still sits there until the notification is
acknowledged, the above at least allows the rest of the desktop system
to start properly and thus gnome-terminal now starts as expected.

The bottom line is this: pemmican-reset should issue the notification
and *exit immediately*, rather than waiting for the user to acknowledge
the message.  The AI I've been working with to diagnose this claims this
to be the offending code:

/usr/lib/python3/dist-packages/pemmican/gui.py:

```
# If nothing is pending (already!), just exit immediately
if not self.notifier.pending:
    self.main_loop.quit()
```

which seems sensible.

LSB release info:
```
No LSB modules are available.
Description:    Ubuntu 24.04.3 LTS
Release:        24.04
```

Package info:

```
kevin at printserver-pi4:~$ dpkg -l pemmican-desktop
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name             Version        Architecture Description
+++-================-==============-============-=========================================================================
ii  pemmican-desktop 1.0.3-0ubuntu1 all          Notify users of Raspberry Pi 5 power issues via freedesktop notifications
```

** Affects: pemmican (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to pemmican in Ubuntu.
Matching subscriptions: pemmican-bugs
https://bugs.launchpad.net/bugs/2120731

Title:
  Raspberry Pi 5 16G, Ubuntu 24.04: pemmican-reset waits for
  notification acknowledgement, prevents full desktop service startup

Status in pemmican package in Ubuntu:
  New

Bug description:
  When pemmican-reset starts and finds that the power supply is
  insufficient, it issues a notification.  This is all well and good.
  But the way it does so is to *wait for the notification to be
  acknowledged* before it exits.  That is *not* all well and good,
  because in doing so it prevents systemd user services such as
  graphical-session from starting.  And this is so because it specifies
  in its systemd service description:

  ```
  [Install]
  WantedBy=graphical-session.target
  ```

  The end result is that if it issues a notification, the graphical
  session service will hang waiting for it to complete until the user
  explicitly acknowledges the notification.  This, in turn, causes xdg-
  desktop-portal to fail to start, and that causes gnome-terminal-
  service to fail to start because it waits for the identifier supplied
  by xdg-desktop-portal to become available via dbus.  And as a
  consequence, you can't start gnome-terminal until you clear the
  notification (and perhaps not even then, since these other service
  startups might well have timed out by the time the notification is
  acknowledged).

  This is a serious bug.  Ubuntu users on Pi5 systems that have power
  supplies that would result in this notification will *all* be affected
  by this in various ways, depending on what user services need to be up
  and running for them to do what they do.


  The bottom line is this: pemmican-reset *must not* block in such a way
  as to prevent anything else from starting.  Its systemd descriptor
  says that it's a one-shot startup:

  ```
  [Service]
  Slice=session.slice
  Type=oneshot
  ExecStart=pemmican-reset
  Restart=on-failure
  RestartSec=1s
  ```

  which means that systemd will wait for it to exit.

  I worked around this issue by supplying my own augmentation to the
  pemmican-reset systemd descriptor:

  ```
  # /etc/systemd/user/pemmican-reset.service.d/fix-deps.conf
  [Unit]
  After=graphical-session.target

  [Install]
  WantedBy=default.target
  ```

  While pemmican-reset still sits there until the notification is
  acknowledged, the above at least allows the rest of the desktop system
  to start properly and thus gnome-terminal now starts as expected.

  The bottom line is this: pemmican-reset should issue the notification
  and *exit immediately*, rather than waiting for the user to
  acknowledge the message.  The AI I've been working with to diagnose
  this claims this to be the offending code:

  /usr/lib/python3/dist-packages/pemmican/gui.py:

  ```
  # If nothing is pending (already!), just exit immediately
  if not self.notifier.pending:
      self.main_loop.quit()
  ```

  which seems sensible.

  LSB release info:
  ```
  No LSB modules are available.
  Description:    Ubuntu 24.04.3 LTS
  Release:        24.04
  ```

  Package info:

  ```
  kevin at printserver-pi4:~$ dpkg -l pemmican-desktop
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name             Version        Architecture Description
  +++-================-==============-============-=========================================================================
  ii  pemmican-desktop 1.0.3-0ubuntu1 all          Notify users of Raspberry Pi 5 power issues via freedesktop notifications
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pemmican/+bug/2120731/+subscriptions