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@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
Bugs, which is subscribed to Ubuntu.
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pemmican/+bug/2120731/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
