Auto-snapshot fails to show notification

Support System Updates
, ,
1

When a snapshot is created before applying a system update, I get this in the log:

[snip]
BTRFS Snapshot saved successfully (0s)
Tagged snapshot '2026-02-04_16-37-10': ondemand
------------------------------------------------------------------------------
Failed to show notification: Cannot autolaunch D-Bus without X11 $DISPLAY
Detecting snapshots ...
[snip]

Not sure why it’s trying to choose an X11 branch, what could I do to diagnose further / fix the issue?
Edit: note that this kinda hard to reproduce, not only do updates need to be there, the last snapshot needs to have occurred quite a while ago (24h I think?). Found a way to trigger it all the time.

Edit 2: Forgot to mention, this issue occurs when using the GUI Add/Remove Programs thing, I have not tried with sudo pacman -Syu yet.

Related: how does Manjaro set up this Timeshift auto-snapshot magic? I’ve not been successful trying it myself in an Arch VM (snapper worked fine but I find it a bit clunky, and Manjaro uses Timeshift anyway). :slight_smile:

2

We don’t. It’s the default timeshift configuration. :man_shrugging:

That said, timeshift does tend to deviate from standards. For instance, it uses cronie for its timed snapshots (or rsync backups), instead of using a systemd timer.

4

Interesting, I took a quick look and noticed I have /usr/share/libalpm/hooks/00-timeshift-autosnap.hook in Manjaro installs but not in Arch installs (with timeshift having been set up). Where does that come from?

[Trigger]
Operation = Upgrade
Type = Package
Target = *

[Action]
Description = Creating Timeshift snapshot before upgrade...
Depends = timeshift
When = PreTransaction
Exec = /usr/bin/timeshift-autosnap
AbortOnFail

EDIT: /usr/bin/timeshift-autosnap is also only on Manjaro (it’s a huge shell script so not pasting it here).

5

From timeshift-autosnap-manjaro, which — as I’ve just seen in the package manager, because I don’t have that package installed — is indeed a Manjaro package.

I didn’t know that, so I apologize. :man_shrugging:

1 Like
6

Dug in some more and realized this is the package being used for auto-snapshots: AUR (en) - timeshift-autosnap (EDIT: I realized I miscommunicated here, this is not the package being used, it’s just the parent of timeshift-autosnap-manjaro). After editing the config file to always trigger snapshots and executing sudo timeshift-autosnap, it did pop up the notification correctly.

[snip]
BTRFS Snapshot saved successfully (0s)
Tagged snapshot '2026-02-04_17-24-09': ondemand
------------------------------------------------------------------------------
Detecting snapshots ...
[snip]

So could it be an issue with Add/Remove Software or its config?

7

I’d rather think it’d be an issue with timeshift-autosnap-manjaro, but I wouldn’t be surprised if it were a problem with pamac (“Add/Remove Software”) either. It is known to have issues… :grin:

1 Like
8

Hah, maybe pamac is still using X11 :upside_down_face:

Edit: probably not, doesn’t show up in the output of xlsclients

9

pamac is display-server-agnostic. Its GUI is only a gtk-based front-end to the pamac-cli command-line utility.

1 Like
10

As you already found out out, that part is from:

/usr/share/libalpm/hooks/00-timeshift-autosnap.hook

Which you have as an AUR for that.

But this part is from:

/etc/grub.d/41_snapshots-btrfs

Pretty sure this is not the problem.

I went through both, and neither seem to have anything to do with wanting to create anything outside the CLI.

Most of us are running the manjaro one, so it has to be your AUR version.:

$ yay -Ss timeshift-autosnap
extra/timeshift-autosnap-manjaro 0.10.0-1 (29.5 KiB 6.6 KiB) (Installed)
    Timeshift auto-snapshot script which runs before package upgrade using Pacman hook.
aur/timeshift-autosnap 0.10.0-1 (+75 2.49)
    Timeshift auto-snapshot script which runs before package upgrade using Pacman hook.

So why not switch?

11

Bummer, wonder where that’s coming from…

Oh I have not installed it via AUR, it’s the same Manjaro one:

$ yay -Ss timeshift-autosnap                                                                                                                                       
extra/timeshift-autosnap-manjaro 0.10.0-1 (29.5 KiB 6.6 KiB) (Installed)
    Timeshift auto-snapshot script which runs before package upgrade using Pacman hook.
aur/timeshift-autosnap 0.10.0-1 (+75 2.49) 
    Timeshift auto-snapshot script which runs before package upgrade using Pacman hook.

$ pacman -Ss timeshift-autosnap                                                                                                                                    
extra/timeshift-autosnap-manjaro 0.10.0-1 [installed]
    Timeshift auto-snapshot script which runs before package upgrade using Pacman hook.
12

:information_source: The only difference between the Manjaro and AUR package is this patch:

13

Thanks! Looks like it’s just an additional flag to disable rsync snapshots (reasonable). What’s causing pamac (or the various scripts / tools involved in the snapshot process) to attempt to show a notification using X11 dbus is still a mystery.

14

I suspect that may be coming from timeshift itself. It does after all have a gtk3-based component.

15

All right, I’ll try to find time to dig into that code. Strange that it works fine when invoked manually on CLI.

16

Found the code in timeshift that triggers this notification:

string s = "notify-send -t %d -u %s -i %s \"%s\" \"%s\" -h %s".printf(
	durationMillis, urgency, "gtk-dialog-" + dialog_type, title, message, hint);

retVal = TeeJee.ProcessHelper.exec_user_async(s);

I set up a test notification by filling in those fields as timeshift would:

notify-send -t 10000 -u low -i gtk-dialog-info "TimeShift" "Test message" -h string:desktop-entry:timeshift-gtk

And that worked just like running timeshift-autosnap earlier, despite all the gtk stuff in there:

image

So the rabbit hole goes further into notify-send. I’m still leaning towards some environment / config mess-up for pamac which makes the code executing believe it’s on X11. notify-send obviously works on Wayland (screenshot above), I doubt the bug is in there.

1 Like
17

This page lists one possible issue that’s aligned with my instinct:

If DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to use D-Bus, by default the process will attempt to invoke dbus-launch with the --autolaunch option to start up a new session bus

Especially since apparently --autolaunch only works in X11 sessions.

Autolaunch of dbus-daemon only works when under an X11 session. It is otherwise disabled because there’s no way for different applications to establish a common instance of the dbus daemon.

In konsole this variable is set:

$ echo $DBUS_SESSION_BUS_ADDRESS
unix:path=/run/user/1000/bus

Perhaps it’s mistakenly not set for me when pamac executes an update? Not sure how to even test this hypothesis without building my own pamac and adding breakpoints / debug logs (and being blocked on iterating unless there are updates)…

Edit: here’s the function that ends up calling notify-send, relevant line:

cmd = "pkexec --user %s env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS ".printf(user) + cmd;

Executing that with sudo on konsole (to simulate pamac running with privileges) shows the notification correctly:

sudo pkexec --user karnage env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS notify-send test

Which lines up with my hypothesis that DBUS_SESSION_BUS_ADDRESS is somehow not being set for me when running a pamac update.

1 Like