Systray applet panics, fails to launch

[guiltiest-gear]

Environment

• Distribution: EndeavourOS
• Graphical environment: AwesomeWM
• Arch-Update version: 4.0.2-1

Arch-Update configuration

# Arch-Update example configuration file (available at <https://github.com/Antiz96/arch-update/blob/main/res/config/arch-update.conf.example>).
# Documentation for this configuration file is available in the arch-update.conf(5) man page (see <https://github.com/Antiz96/arch-update/blob/main/doc/man/arch-update.conf.5.scd>).
# List of available options (with their default value) below, un-comment one to enable it.

#NoColor
#NoVersion
#NoAUR
NoFlatpak
#NoNotification
#NoALHPCheck
#NewsNum=5
#NewsTimeout=10
#UpdateCheckTimeout=30
#AURHelper=paru
#PrivilegeElevationCommand=sudo
#KeepOldPackages=3
#KeepUninstalledPackages=0
#DiffProg=$DIFFPROG
#TrayIconStyle=blue
#ColorblindMode

Description of the bug

When attempting to run arch-update --tray, instead of launching normally, the systray applet panics and fails to launch. I've attempted looking through the source code and grepping for the exact error message, but to no avail.

Screenshots / Logs

==> Starting the Arch-Update systray applet
[2026-07-30T03:17:50Z DEBUG arch_update_tray::tray] Icon set or updated: arch-update_updates-available-blue                                                                                   

thread 'main' (859576) panicked at src/tray.rs:298:10:
Unable to start the systray applet: Watcher(ServiceUnknown("The name is not activatable"))
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Additional context

[Antiz96]

Hi,

Thanks for the report!

This issue is a bit unexpected though... The main reason why this would happen is if you're trying to start the systray applet from an environment that cannot "host" it. For instance, a TTY / non-graphical environment, a graphical environment without a panel that have support for tray icons or an environment without a running / healthy D-Bus session.

Can you confirm that you have a panel / bar running on your AwesomeWM environment and that said panel / bar supports tray icons?
Is D-bus running properly (e.g. does the busctl --user status output looks okay)?
Also, is this issue reproducible? Does it panic every time?

[guiltiest-gear]

Hi there,

I'm just as baffled as you are about this issue, and I'll do my best to provide info about the problem.

Can you confirm that you have a panel / bar running on your AwesomeWM environment and that said panel / bar supports tray icons?

Yes, I do in fact have a bar running currently and there is in fact a systray widget in said bar, as can be seen below.

(Apologies for the image being weirdly sized, I'm not sure how to take a better screenshot of the tray.)

Is D-bus running properly (e.g. does the busctl --user status output looks okay)?

Checking my process list, D-bus is in fact running, and checking busctl --user status, as far as I can tell with the output, everything looks as it should, at least from initial looks? The output of the command is as follows:

BusAddress=unix:path=/run/user/1000/bus
BusScope=user
BusID=16c414e1d71a9e3a68fe91d7ac73bf05
PID=1339
PIDFD=yes
PPID=1
TTY=n/a
UID=1000
EUID=1000
SUID=1000
FSUID=1000
OwnerUID=1000
GID=1000
EGID=1000
SGID=1000
FSGID=1000
SupplementaryGIDs=3 954 960 961 963 981 990 998 1000
Comm=systemd
CommandLine=/usr/lib/systemd/systemd --user
CGroup=/user.slice/user-1000.slice/user@1000.service/init.scope
Unit=user@1000.service
Slice=user-1000.slice
UserUnit=init.scope
UserSlice=-.slice
Session=n/a
AuditLoginUID=1000
AuditSessionID=3
EffectiveCapabilities=cap_wake_alarm
PermittedCapabilities=cap_wake_alarm
InheritableCapabilities=cap_wake_alarm
BoundingCapabilities=cap_chown cap_dac_override cap_dac_read_search 
        cap_fowner cap_fsetid cap_kill cap_setgid 
        cap_setuid cap_setpcap cap_linux_immutable cap_net_bind_service 
        cap_net_broadcast cap_net_admin cap_net_raw cap_ipc_lock 
        cap_ipc_owner cap_sys_module cap_sys_rawio cap_sys_chroot 
        cap_sys_ptrace cap_sys_pacct cap_sys_admin cap_sys_boot 
        cap_sys_nice cap_sys_resource cap_sys_time cap_sys_tty_config 
        cap_mknod cap_lease cap_audit_write cap_audit_control 
        cap_setfcap cap_mac_override cap_mac_admin cap_syslog 
        cap_wake_alarm cap_block_suspend cap_audit_read cap_perfmon 
        cap_bpf cap_checkpoint_restore

Also, is this issue reproducible? Does it panic every time?

Yes, it does in fact panic every time I attempt to run it, this is not a one-off issue. Here is the output of three individual runs when using RUST_LOG=DEBUG arch-update --tray

$ RUST_LOG=DEBUG arch-update --tray
==> Starting the Arch-Update systray applet
[2026-07-30T23:40:46Z DEBUG arch_update_tray::tray] Icon set or updated: arch-update-blue                                                                                                     

thread 'main' (29352) panicked at src/tray.rs:298:10:
Unable to start the systray applet: Watcher(ServiceUnknown("The name is not activatable"))
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

$ RUST_LOG=DEBUG arch-update --tray
==> Starting the Arch-Update systray applet
[2026-07-30T23:40:47Z DEBUG arch_update_tray::tray] Icon set or updated: arch-update-blue                                                                                                     

thread 'main' (29461) panicked at src/tray.rs:298:10:
Unable to start the systray applet: Watcher(ServiceUnknown("The name is not activatable"))
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

$ RUST_LOG=DEBUG arch-update --tray
==> Starting the Arch-Update systray applet
[2026-07-30T23:40:48Z DEBUG arch_update_tray::tray] Icon set or updated: arch-update-blue                                                                                                     

thread 'main' (29566) panicked at src/tray.rs:298:10:
Unable to start the systray applet: Watcher(ServiceUnknown("The name is not activatable"))
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I would like to note I installed the package from the Chaotic AUR, but I'll try and build the package on my system instead to see if this potentially makes a difference. While I'm not confident it will, I'd like to eliminate any possible variables in this problem.

[guiltiest-gear]

Alright, I've successfully built the package on my system (using BUILDDIR=/tmp/makepkg makepkg -scri), once again attempted to run RUST_LOG=DEBUG arch-update --tray, but once again, same exact result.

$ RUST_LOG=DEBUG arch-update --tray
==> Starting the Arch-Update systray applet
[2026-07-30T23:52:20Z DEBUG arch_update_tray::tray] Icon set or updated: arch-update_updates-available-blue                                                                                   

thread 'main' (48059) panicked at src/tray.rs:298:10:
Unable to start the systray applet: Watcher(ServiceUnknown("The name is not activatable"))
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This is just continuing to absolutely baffle me as to why this error is even occurring, maybe it's something I missed in the output of busctl --user status?

I'm still entirely baffled to what could even be causing this problem in the first place, but ideally it can be determined sooner than later.