Fix race condition between AppImage daemon and KDE PowerDevil

[LightWayUp]

This fixes issue 48 "Cannot see volumes come and go on Kubuntu 20.04".

Earlier attempt to fix the issue (#233) implemented a retry-after-timeout, with the idea that the required services are simply "occasionally too slow to come up". With the 0.5s timeout, indeed most of the time the services are ready when AppImage daemon checks for their availability.
However, that doesn't actually fix the issue — a race condition present somewhere, it just masks it.

This change addresses the race condition itself via systemd dependency and ordering directives, no arbitrary sleeps are involved.

Changes

appimaged.service systemd unit file

• Add Slice=background.slice to allow systemd to deprioritize appimaged background service, as AppImage daemon does not provide critical or time-sensitive services
• New line at the end of appimaged service unit file
• Fix race condition between AppImage daemon and KDE PowerDevil

systemd service setup prerequisite

• Update the already-installed appimaged service unit file if it is outdated
  Use LAUNCHED_BY_SYSTEMD environment variable value as a quick hack to check the revision of the service unit file. This is fine because the environment variable's value isn't being used elsewhere anyway.

Tip

Ideally to determine whether to update the existing service unit file, its content should be compared against the content embedded in the executing version of AppImage daemon.
The user would still be able to alter service unit properties and behaviors to their needs via "drop in" configuration file (appimaged.service.d/local.conf), so there should be no reason to modify the service unit file other than an actual update from AppImage daemon itself.

Details

AppImage daemon wants to ensure that signals from
org.gtk.vfs.UDisks2VolumeMonitor and org.kde.Solid.Device interfaces would be sent, so it checks for relevant names on the bus.
The check isn't necessary for AppImage daemon to monitor the messages on D-Bus, it just would like to send a notification informing the user, in the case that such messages are likely never going to be sent (due to the services being absent).

Backgrounds

Volume monitoring

GNOME desktop and derivatives (MATE, Cinnamon) and Xfce use GVfs UDisks 2 volume monitor, a daemon process.

• D-Bus service name: org.gtk.vfs.UDisks2VolumeMonitor
• systemd service: gvfs-udisks2-volume-monitor.service

KDE Plasma desktop uses Solid device integration framework, with UDisks 2 backend, a library/framework to be used by applications.

Because its not an application providing a service, there's nothing to check against on D-Bus. It was assumed that if the PowerDevil service, which also uses Solid, is available on the bus, there would likely be other running KDE components using Solid (KIO, Dolphin, ...), and AppImage daemon would therefore receive signals from interface org.kde.Solid.Device just fine.

• D-Bus service name of PowerDevil: org.kde.Solid.PowerManagement
• systemd service of PowerDevil: plasma-powerdevil.service

systemd and D-Bus services

Both gvfs-udisks2-volume-monitor.service and plasma-powerdevil.service are "static" systemd services of type dbus.

• Static services are ones with no [Install] section, they're only started if other units depend on them.
• Unless they're also services with Type=dbus, such services are "D-Bus activated".

D-Bus activation

If a D-Bus activated service isn't running yet, the D-Bus call to it will block, dbus-daemon will start the service, then send the message to it, and finally deliver the reply back to the caller.

This works fine with GVfs UDisks 2 volume monitor. AppImage daemon sends a D-Bus method call and blocks, GVfs UDisks 2 volume monitor is activated by dbus-daemon, a reply is sent back, then AppImage daemon continues.

Unfortunately with PowerDevil, there are 2 issues, both out of our control.

1. Despite being marked as Type=dbus in the systemd service unit file, PowerDevil is not D-Bus activatable, because there is no corresponding D-Bus service file /usr/share/dbus-1/services/org.kde.Solid.PowerManagement.service.

Out of all KDE services, it just happens that PowerDevil and PlasmaShell seem to be the only 2 with this issue.
This can be verified by looking at appimaged service's journal logs, in cases where it starts before PowerDevil:

appimaged.AppImage: 2025/07/08 00:00:00 Notice: Cannot introspect org.kde.Solid on this system The name org.kde.Solid.PowerManagement was not provided by any .service files
appimaged.AppImage: 2025/07/08 00:00:00 ----------------------------
appimaged.AppImage: 2025/07/08 00:00:00 Notification:
appimaged.AppImage: 2025/07/08 00:00:00 Cannot see volumes come and go
appimaged.AppImage: 2025/07/08 00:00:00 Not implemented yet for this kind of system

This leads to unexpected behavior. When AppImage daemon sends a D-Bus method call, PowerDevil does not start, instead the call fails with the reason that The name org.kde.Solid.PowerManagement was not provided by any .service files.

2. For reasons, PowerDevil is a QGuiApplication (Qt application with QML GUI) rather than a QCoreApplication (Qt console application), meaning that starting it requires a X or Wayland display server, which is only started in a graphical user login session.

This is normally fine when appimaged service starts at user login, but problematic if "user lingering" is enabled as explained later.

systemd static services

PowerDevil is depended on by plasma-workspace.target. plasma-workspace-{x11/wayland}.target are in turn also static, and only requested to be started by startplasma-{x11/wayland} executable binaries, which is executed by SDDM (the display manager responsible for login screen) when the user chooses a session and logs into it.

Combined with being a GUI application, this means plasma-powerdevil.service can only ever be started after login.

systemd "user lingering"

systemd user services are managed by systemd user service manager.

• Normally, systemd user services are run when a login session exists for that user.
  Usually this means, the user services are started after login, and stopped before logout/shutdown.
• If "user lingering" is enabled for a user, that user's user service manager is spawned as soon as possible after boot, before any login sessions are created.
  The user services are started at boot, and stopped at shutdown.
  This can be useful for long-running user services, for example rootless Docker.

Issue of current appimaged.service unit file

Previously, appimaged service unit uses WantedBy=default.target, as in, default.target wants/depends on appimaged.service and will cause it to start.
default.target of user units is started when the user service manager is started.

Note

Not to be confused with default.target of system units, which is started on boot, and is often aliased to multi-user.target or graphical.target system units.

From the above, we can understand that the following sequence of events are possible:

0. In all cases, PowerDevil cannot be started automatically via D-Bus activation, when AppImage daemon sends a method call.

1. Without user lingering:

A race condition exists between appimaged service and PowerDevil.

1. i. AppImage daemon runs monitorUdisks() before PowerDevil acquires the name on the bus. AppImage daemon assumes that volumes can not be monitored, and sends a notification "Cannot see volumes come and go".

1. ii. AppImage daemon runs monitorUdisks() after PowerDevil acquires the name on the bus, everything is fine.

2. With user lingering:

The issue is much more apparent. AppImage daemon always runs monitorUdisks() before PowerDevil is even started, assumes that volumes can not be monitored, and sends a notification "Cannot see volumes come and go".

Solution

What doesn't work

1. Add the missing D-Bus service file for PowerDevil

Create the D-Bus service file with the following content:

[D-BUS Service]
Name=org.kde.Solid.PowerManagement
Exec=/usr/lib/x86_64-linux-gnu/libexec/org_kde_powerdevil
SystemdService=plasma-powerdevil.service

Place the file at ${XDG_DATA_HOME}/dbus-1/services/org.kde.Solid.PowerManagement.service (per user) or /usr/local/share/dbus-1/services/org.kde.Solid.PowerManagement.service (system wide).

Now, when AppImage daemon sends a D-Bus method call to PowerDevil, it successfully blocks as expected, waits for PowerDevil to be started by dbus-daemon, and continues after receiving a reply. No more retries and arbitrary sleeps are needed.

What's the problem:
If the system doesn't actually have PowerDevil (for example a system with GNOME desktop environment), this solution just erroneously created a seemingly D-Bus activatable service that will always fail.
AppImage daemon can't reliably add or remove the service file when PowerDevil is installed or uninstalled either. The service file needs to come together with PowerDevil package.

2. Poll for PowerDevil service status

Let appimaged service be started by default.target, and poll for PowerDevil service status until it is active or a timeout is reached.

What's the problem:
This is essentially the current implementation, just with multiple retries, and a longer timeout or an infinite wait.

• If a timeout is set, a user who has user lingering enabled and spends too much time on the login screen will still incorrectly see the notification upon login.
• If there's no timeout, AppImage daemon will hang forever in a loop if PowerDevil is not started.

Proper solution

• plasma-powerdevil.service and graphical-session.target are added to WantedBy= directive in addition to default.target
  • Instead of starting AppImage daemon and checking/waiting for the availability of PowerDevil service, now AppImage daemon is started because of it.
  • default.target is retained, so appimaged service still starts on systems without PowerDevil service installed.
  • graphical-session.target is used as a fallback, in case PowerDevil is installed on the system, but will not be used for this session.
• Both are also added to After= directive
  • appimaged service is definitely started after them, if they are being started and succeed.
  • appimaged service is still started if they fail or aren't installed.

Tip

Both GVfs UDisks 2 volume monitor and PowerDevil services are started and stopped as part of graphical sessions.
Why not simply use WantedBy=graphical-session.target to always start at the right time?

Some distributions and environments don't comply with systemd's rules despite "supporting systemd".
Take Linux Mint Cinnamon Edition for example, the cinnamon session executable never starts the passive graphical-session.target unit. This can be verified in a running Cinnamon session, the status of graphical-session.target shows Active: inactive (dead).
GVfs UDisks 2 volume monitor has the correct status Active: active (running), as its already correctly configured by GNOME developers.

• ExecCondition= condition check directive is added to skip appimaged service being started, when PowerDevil service isn't ready yet, but is reasonably predicted to have started at a near future point in time.
  Specifically, it'll skip being started as a dependency of default.target if all of the following are true:
  • gvfs-udisks2-volume-monitor.service does not exist or is not enabled
  • plasma-powerdevil.service does exist, is not active, and is enabled
  • graphical-session.target is not active

New appimaged service unit file

[Unit]
Description=AppImage system integration daemon
After=syslog.target network.target plasma-powerdevil.service graphical-session.target

[Service]
ExecCondition=/bin/sh -c ' \
    unit_status() { \
        systemctl --user --quiet "is-$${1}" "$$2"; \
    }; \
    POWERDEVIL_SERVICE="plasma-powerdevil.service"; \
    unit_status enabled gvfs-udisks2-volume-monitor.service || \
    unit_status active "$$POWERDEVIL_SERVICE" || \
    ! unit_status enabled "$$POWERDEVIL_SERVICE" || \
    unit_status active graphical-session.target; \
'
ExecStart=/home/user/Applications/appimaged.AppImage
RestartSec=3
Restart=always
Environment=LAUNCHED_BY_SYSTEMD=2
Slice=background.slice
LimitNOFILE=65536

[Install]
WantedBy=default.target plasma-powerdevil.service graphical-session.target

ExecCondition shell script

unit_status() {
    systemctl --user --quiet "is-${1}" "$2"
}

POWERDEVIL_SERVICE="plasma-powerdevil.service"
unit_status enabled gvfs-udisks2-volume-monitor.service || \
unit_status active "$POWERDEVIL_SERVICE" || \
! unit_status enabled "$POWERDEVIL_SERVICE" || \
unit_status active graphical-session.target

The new sequence of events is illustrated as follows:

Edge case

The new appimaged service unit would solve the erroneous "Cannot see volumes come and go" notification issue, at the expense of AppImage daemon not being started in a specific edge case.

To encounter this case:

1. GVfs UDisks 2 volume monitor must not be installed
2. PowerDevil must be installed and the service file must be enabled (not masked)
3. PowerDevil must not be started or running
4. The session must not start graphical-session.target unit

If all of the above are true, appimaged service will skip being started by default.target, but will not be started by anything else later.

The fundamental reason is that, we can never predict whether PowerDevil service will be started or not until it is actually started, because it is a static service with no active WantedBy=, and is only depended on by other parts of a session, a session that user may or may not choose to use.

I believe this fix should be incorporated, as

• It is logically correct
• The issue is almost certainly more prevalent than the described exotic setup.

Should one actually encounters the edge case, and would like to still have AppImage daemon service start, they can remove the ExecCondition= directive via drop-in configuration file.

[github-actions]

Build for testing:
artifacts
Use at your own risk.

[probonopd]

Thanks for the detailed analysis @LightWayUp. Would be good to hear from users on different systems how well this works.

[github-actions]

Build for testing:
artifacts
Use at your own risk.

[github-actions]

Build for testing:
artifacts
Use at your own risk.

[LightWayUp]

Thanks for the detailed analysis @LightWayUp. Would be good to hear from users on different systems how well this works.

After more investigation, I've found the root cause of the issue, that leads to the discrepancy in behavior between sending D-Bus calls to KDE Plasma's plasma-powerdevil.service and to GNOME's gvfs-udisks2-volume-monitor.service.
I've significantly modified the original post to correct some points and add more context on the issue. In short:

• PowerDevil is supposed to be D-Bus activatable, but isn't due to a missing D-Bus service file, this is why calling its method fails for AppImage daemon
• The issue can only be fixed by KDE

The solution didn't change much though, most important part was adding a reverse dependency on graphical-session.target as a fallback.

---

I have tested the fix across various distributions and desktop environments, and can verify that it works correctly in all except one case, as described in the Edge case section above. It requires a very specific and uncommon setup to be hit, so in my opinion fixing issue #48 outweighs the potential disadvantage.