Unable to start dunst notification daemon for user

[hjpotter92]

Crossposted from super user

I did a clean arch install with only XDM and i3 to serve as login/window managers. I have also installed dunst package; and according to arch wiki nothing else is required for it to work.

However, when trying to send notifications, I receive:

Unable to send notification: Error calling StartServiceByName for org.freedesktop.Notifications: Timeout was reached

The troubleshoot section on same wiki page suggests assignment of DISPLAY variable. I have the following in my .xinitrc:

source /etc/X11/xinit/xinitrc.d/50-systemd-user.sh

which does exactly this:

➜ cat /etc/X11/xinit/xinitrc.d/50-systemd-user.sh     
#!/bin/sh

systemctl --user import-environment DISPLAY XAUTHORITY

if command -v dbus-update-activation-environment >/dev/null 2>&1; then
        dbus-update-activation-environment DISPLAY XAUTHORITY
fi

Checking at dunst's FAQ, it mentions availability of DBUS_SESSION_BUS_ADDRESS variable. And to check the gdbus command for running notification daemons:

➜ gdbus call --session --dest org.freedesktop.DBus --object-path /org/freedesktop/Dbus --method org.freedesktop.DBus.ListNames
(['org.freedesktop.DBus', ':1.40', 'org.freedesktop.systemd1', 'org.a11y.Bus', ':1.20', ':1.21', 'net.tenshu.Terminator20x1a6021154d881c', ':1.0', ':1.1', 'org.PulseAudio1', 'org.pulseaudio.Server', ':1.2', ':1.16', ':1.17', ':1.18', ':1.19'],)

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

➜ echo $DISPLAY 
:0

I do have the dunst service listed in /usr/share/dbus-1/services directory.

-rw-r--r-- 1 root root  64 Oct 23 03:43 ca.desrt.dconf.service
-rw-r--r-- 1 root root 107 Sep  6 00:40 org.a11y.Bus.service
-rw-r--r-- 1 root root  68 Feb 20 10:29 org.dharkael.Flameshot.service
-rw-r--r-- 1 root root 116 Aug  1  2018 org.freedesktop.ColorHelper.service
lrwxrwxrwx 1 root root  51 Feb 20 18:37 org.freedesktop.systemd1.service -> ../system-services/org.freedesktop.systemd1.service
-rw-r--r-- 1 root root  60 Oct 27 22:09 org.gnome.GConf.service
-rw-r--r-- 1 root root 111 Sep  5 05:36 org.gtk.GLib.PACRunner.service
-rw-r--r-- 1 root root 100 Jan  2 17:13 org.knopwob.dunst.service
-rw-r--r-- 1 root root  56 Nov 22  2017 org.xfce.calendar.service
-rw-r--r-- 1 root root 115 Jan 28 05:22 org.xfce.FileManager.service
-rw-r--r-- 1 root root  56 Nov 22  2017 org.xfce.orage.service
-rw-r--r-- 1 root root 124 Jan 28 05:22 org.xfce.Thunar.FileManager1.service
-rw-r--r-- 1 root root 110 Jan 28 05:22 org.xfce.Thunar.service

According to this blog post; I should switch to dunst as my notification service. But I have no idea which notification service is my current one!

I do have 2 separate dbus.service listed as running in my systemctl status list; one in the system.slice tree and another in [email protected] tree.

Any pointers as to how should I configure my dbus daemon would be helpful,

Installation info

• Version: 1.3.2 (2018-05-06)

• Install type: from pacman

• Distro and version: archlinux

[bebehei]

Just run dunst in a terminal. What does it say?

[hjpotter92]

@bebehei It starts from terminal, but not as a part of user service.

[bebehei]

What does

systemctl status --user dunst

report?

[hjpotter92]

● dunst.service - Dunst notification daemon
   Loaded: loaded (/usr/lib/systemd/user/dunst.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2019-03-07 03:25:45 IST; 1h 33min ago
     Docs: man:dunst(1)
 Main PID: 8666 (code=exited, status=1/FAILURE)

Mar 07 03:25:45 hedwig systemd[709]: Starting Dunst notification daemon...
Mar 07 03:25:45 hedwig dunst[8666]: cannot open display
Mar 07 03:25:45 hedwig systemd[709]: dunst.service: Main process exited, code=exited, status=1/FAILURE
Mar 07 03:25:45 hedwig systemd[709]: dunst.service: Failed with result 'exit-code'.
Mar 07 03:25:45 hedwig systemd[709]: Failed to start Dunst notification daemon.

[bebehei]

Duplicate of #347

[hjpotter92]

@bebehei I am fetching DISPLAY variable. I did go through the linked issue.

[bebehei]

• Are you sure, that the sourced file actually gets executed?
• Are you sure, that the DISPLAY variable is set, when systemctl is called?

DISPLAY is definitely either unset or set to a wrong value.

[hjpotter92]

In the journalctl logs, I can see display value being provided to other dbus services.

Check the logs below:

Mar 07 06:17:49 hedwig dbus-daemon[497]: [system] Activating via systemd: service name='org.freedesktop.RealtimeKit1' unit='rtkit-daemon.service' requested by ':1.15' (uid=1000 pid=712 comm="/usr/bin/pulseaudio --daemonize=no ")
Mar 07 06:17:49 hedwig systemd[1]: Starting RealtimeKit Scheduling Policy Service...
Mar 07 06:17:49 hedwig dbus-daemon[497]: [system] Successfully activated service 'org.freedesktop.RealtimeKit1'
Mar 07 06:17:49 hedwig systemd[1]: Started RealtimeKit Scheduling Policy Service.
Mar 07 06:17:49 hedwig audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=rtkit-daemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 07 06:17:49 hedwig rtkit-daemon[713]: Successfully called chroot.
Mar 07 06:17:49 hedwig rtkit-daemon[713]: Successfully dropped privileges.
Mar 07 06:17:49 hedwig rtkit-daemon[713]: Successfully limited resources.
Mar 07 06:17:49 hedwig rtkit-daemon[713]: Running.
Mar 07 06:17:49 hedwig rtkit-daemon[713]: Canary thread running.
Mar 07 06:17:49 hedwig rtkit-daemon[713]: Watchdog thread running.
Mar 07 06:17:49 hedwig dbus-daemon[497]: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service' requested by ':1.16' (uid=0 pid=713 comm="/usr/lib/rtkit-daemon ")
Mar 07 06:17:49 hedwig kernel: audit: type=1130 audit(1551919669.497:53): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=rtkit-daemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 07 06:17:49 hedwig systemd[1]: Starting Authorization Manager...
Mar 07 06:17:49 hedwig polkitd[716]: Started polkitd version 0.116
Mar 07 06:17:49 hedwig polkitd[716]: Loading rules from directory /etc/polkit-1/rules.d
Mar 07 06:17:49 hedwig polkitd[716]: Loading rules from directory /usr/share/polkit-1/rules.d
Mar 07 06:17:49 hedwig polkitd[716]: Finished loading, compiling and executing 2 rules
Mar 07 06:17:49 hedwig dbus-daemon[497]: [system] Successfully activated service 'org.freedesktop.PolicyKit1'
Mar 07 06:17:49 hedwig systemd[1]: Started Authorization Manager.
Mar 07 06:17:49 hedwig audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=polkit comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 07 06:17:49 hedwig kernel: audit: type=1130 audit(1551919669.594:54): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=polkit comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 07 06:17:49 hedwig polkitd[716]: Acquired the name org.freedesktop.PolicyKit1 on the system bus
Mar 07 06:17:49 hedwig rtkit-daemon[713]: Successfully made thread 712 of process 712 (/usr/bin/pulseaudio) owned by '1000' high priority at nice level -11.
Mar 07 06:17:49 hedwig rtkit-daemon[713]: Supervising 1 threads of 1 processes of 1 users.
Mar 07 06:17:50 hedwig rtkit-daemon[713]: Supervising 1 threads of 1 processes of 1 users.
Mar 07 06:17:50 hedwig rtkit-daemon[713]: Successfully made thread 789 of process 712 (/usr/bin/pulseaudio) owned by '1000' RT at priority 5.
Mar 07 06:17:50 hedwig rtkit-daemon[713]: Supervising 2 threads of 1 processes of 1 users.
Mar 07 06:17:50 hedwig dbus-daemon[679]: [session uid=1000 pid=679] Activating via systemd: service name='org.a11y.Bus' unit='at-spi-dbus-bus.service' requested by ':1.3' (uid=1000 pid=788 comm="/usr/bin/python2 /bin/terminator ")
Mar 07 06:17:50 hedwig systemd[666]: Starting Accessibility services bus...
Mar 07 06:17:50 hedwig dbus-daemon[679]: [session uid=1000 pid=679] Successfully activated service 'org.a11y.Bus'
Mar 07 06:17:50 hedwig systemd[666]: Started Accessibility services bus.
Mar 07 06:17:50 hedwig at-spi-bus-launcher[790]: dbus-daemon[796]: Activating service name='org.a11y.atspi.Registry' requested by ':1.0' (uid=1000 pid=788 comm="/usr/bin/python2 /bin/terminator ")
Mar 07 06:17:50 hedwig at-spi-bus-launcher[790]: dbus-daemon[796]: Successfully activated service 'org.a11y.atspi.Registry'
Mar 07 06:17:50 hedwig at-spi-bus-launcher[790]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
Mar 07 06:17:50 hedwig rtkit-daemon[713]: Supervising 2 threads of 1 processes of 1 users.
Mar 07 06:17:50 hedwig rtkit-daemon[713]: Successfully made thread 801 of process 712 (/usr/bin/pulseaudio) owned by '1000' RT at priority 5.
Mar 07 06:17:50 hedwig rtkit-daemon[713]: Supervising 3 threads of 1 processes of 1 users.

I am, ofcourse, assuming that the requested by ':1.3' etc. appearing in dbus logs are the DISPLAY values,

[tsipinakis]

Thanks for the very detailed report and to be honest: We also have no clue what's happening here so it's basically a guessing game, but a very good opportunity to add some user documentation for this.

Some ideas that come to mind:

• Debian has the following script in /etc/X11/Xsession.d/20dbus_xdg-runtime, some research shows that Xsession is executed later in the startup process so try adding that there.

• If it still doesn't work try editing the systemd service file with (echo $DISPLAY $DBUS_SESSION_BUS_ADDRESS $XAUTHORITY; dunst) to see if the environment is actually being run.

Edit: Also: try setting --verbose --systemd to dbus-update-activation-environment, it'll print out the values it's setting and also try to import them into systemd.

[hjpotter92]

Temporarily fixed by placing exec_always --no-startup-id dunst in my i3 config.

[hjpotter92]

I did yet another clean installation on a different machine. This time, for dunst; I noticed that the service was disabled.

Doing a systemctl --user enable dunst and then starting it fixed this.

[tsipinakis]

Glad you fixed it, but this shouldn't have been necessary. We don't enable the service on purpose, dbus is supposed to start it automatically when a notification comes through.

[hxmuller]

I had similar problem. I am using i3wm and lightdm on Debian Bullseye

dunst is pulled in as a recommends of i3. I have been spending time learning journalctl and discovered during boot:

systemd[###]: Failed to start Dunst notification daemon.

I was getting that message twice during boot.

After much investigation, it became clear that dunst.service did not obtain the user's DISPLAY and XAUTHORITY variables. I discovered two methods, both requiring user intervention.

In the first method, both instances of the error message are eliminated.

$ systemctl --user disable dunst

This removes the link /etc/systemd/user/default.target.wants/dunst.service

$ systemctl --user --full edit dunst

Under [Service] I added:

Environment=DISPLAY=:0
Environment=XAUTHORITY=/var/run/lightdm/user_name/xauthority

Afterwards, enabled the service:

$ systemctl --user enable dunst

The dunst.service runs without error afterwards.

The second method is simpler, but only eliminates one of the errors:

This was performed on a fresh default install of dunst.

$ mkdir $HOME/.config/environment.d
$ vi $HOME/.config/environment.d/envars.conf

In that file, I added the same as above:

DISPLAY=:0
XAUTHORITY=/var/run/lightdm/user_name/xauthority

It is not necessary to enable the dunst.service as it is enabled by default for the user. One of the error messages regarding dunst failing to start will still be present, but seconds later during the boot the dunst service will start. I opted for this method a in case I require additional user services which need the environment variables.

[kofm]

On Arch + dwm, same problem.

Using

$ systemctl --user --full edit dunst

and adding

Environment=DISPLAY=:0

under [Service] solved the problem

[hjpotter92]

Faced this issue again with arch + xdm + i3 setup. I think this happens because the ~/.xinitrc does not get populated with the following snippet:

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 done
 unset f
fi

which should actually source the following:

#!/bin/sh

systemctl --user import-environment DISPLAY XAUTHORITY

if command -v dbus-update-activation-environment >/dev/null 2>&1; then
    dbus-update-activation-environment DISPLAY XAUTHORITY
fi

[dsh2]

I like to use dunst on remote hosts via ssh; so I think an approach via systemctl --user import-environment DISPLAY is preferable as DISPLAY might have changing values.

[fwsmit]

If you want to use dunst m over ssh you will only need to forward DBus. After you've done that you can just simply notify-send from your remote box. See https://serverfault.com/questions/405518/how-to-configure-d-bus-and-ssh-x-forwarding-to-prevent-ssh-from-hanging-on-exit.

[dsh2]

That's a nice idea, @fwSmit, I haven't though about yet. Usually, dunst is not the only X application I use on other machines, though. Still, forwarding D-Bus is probably less expensive in regard to network load, right? So, maybe even if I do need X for other applications, I should still go for D-Bus-dunst. Is that correct?

[fwsmit]

Still, forwarding D-Bus is probably less expensive in regard to network load, right?

Yeah not only that, but I don't think it would work that great if you X-forward dunst AND have it running on your local machine. The two might clash. Keep in mind that both X forwarding and dbus forwarding might pose a security risk when connecting to untrusted machines.

[RedDofamine]

Temporarily fixed by placing exec_always --no-startup-id dunst in my i3 config.

I tried everything! Only your version worked for me.

[yuceltoluyag]

Faced this issue again with arch + xdm + i3 setup. I think this happens because the ~/.xinitrc does not get populated with the following snippet:

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 done
 unset f
fi

which should actually source the following:

#!/bin/sh

systemctl --user import-environment DISPLAY XAUTHORITY

if command -v dbus-update-activation-environment >/dev/null 2>&1; then
    dbus-update-activation-environment DISPLAY XAUTHORITY
fi

After doing that, did you enable or disable the service again ? @hjpotter92

I disabled it seems to work fine

systemctl --user disable dunst

[Vladimir-csp]

Hi. I've stumbled on a related problem. On those of my hosts where I rarely start graphical sessions, [email protected]'s began failing. I do not know when and how dunst got into default.target.wants, but this was the reason. I have a different question: why at all try to start dunst via systemd? Dunst only makes sense in a particular graphical session.

Systemd --user stuff:

1. works independent of X (dunst just fails if there is no X and has no graceful handling of this situation),
2. is single per-user (how would dunst start if a user decides to run a second graphical session?).

XDG autostart seems to be a much more fitting place to start a notification daemon.

[fwsmit]

You're not forced to use systemd service starting. If you want, just start it with your WM/DM or autostart upon sending a notification. Systemd can be used for starting things in a graphical environment. You have to set that up in your environment. Otherwise the service won't start. Xdg autostart could probably work and you're free to use it and document your usage for other people. I don't think dunst needs to implement something for that.

[U1s2e3r4n5a6m7e]

I get the same error most of the time

username@hostname ~ $ dunst      
WARNING: No icon found in path: 'dialog-information'
WARNING: No icon found in path: 'dialog-information'
WARNING: No icon found in path: 'dialog-information'
WARNING: No icon found in path: 'dialog-information'
WARNING: No icon found in path: 'dialog-information'
zsh: segmentation fault (core dumped)  dunst
username@hostname ~ $

$ systemctl status --user dunst.service

Click to expand!

× dunst.service - Dunst notification daemon Loaded: loaded (/home/USERNAME/.config/systemd/user/dunst.service; static) Active: failed (Result: core-dump) since Sun 2022-06-05 16:59:33 ; 3min ago Docs: man:dunst(1) Main PID: 372812 (code=dumped, signal=TRAP) CPU: 80ms

Jun 05 16:59:32 HOSTNAME systemd[456]: Starting Dunst notification daemon... Jun 05 16:59:32 HOSTNAME dunst[372812]: WARNING: Cannot open X11 display. Jun 05 16:59:32 HOSTNAME dunst[372812]: ERROR: [ get_x11_output:0065] Couldn't initialize X11 output. Aborting... Jun 05 16:59:33 HOSTNAME systemd-coredump[372817]: [🡕] Process 372812 (dunst) of user 1000 dumped core.

                                                Module linux-vdso.so.1 with build-id 4bbdd9447359021631434950a65998efe247ea02
                                                Module libbrotlicommon.so.1 with build-id acfd597a977c8087bb6184383daae2e828a9ce42
                                                Module libpthread.so.0 with build-id 95ae4f30a6f12ccbff645d30f8e1a3ee23ec7d36
                                                Module libblkid.so.1 with build-id 140694a62d8d4d07c6c320a501f948dd1b389d73
                                                Module liblzma.so.5 with build-id 28b40c7af8098a66af6ee093b6986b91cad7694d
                                                Module libzstd.so.1 with build-id 3bccb8fe08e48d5ea135b1d0f99de0d771dd752f
                                                Module libXdmcp.so.6 with build-id d864159ab0008415667db8d5f251696d75c90df2
                                                Module libXau.so.6 with build-id 60db1eac70f819bea9d4c366603c1583067510b4
                                                Module libbrotlidec.so.1 with build-id 66c54e9301f7e102ecc1d88547e5f0e8a056fe22
                                                Module libbz2.so.1.0 with build-id 919597c477c9b2cb9cdbb7745ed6494ac0e6da60
                                                Module libdatrie.so.1 with build-id 6fe3b6ece2c8e7d11869fa051375128d8f808f58
                                                Module libexpat.so.1 with build-id 113bb5a3e9ad856801bfcfc029102c9bdc13d67e
                                                Module libgraphite2.so.3 with build-id ce58945ebb55b86d3a4e717b6eae29efc4720d8e
                                                Module libpcre.so.1 with build-id 845483dd0acba86de9f0313102bebbaf3ce52767
                                                Module libffi.so.8 with build-id f0a9586cf0f42d2b9971bd1065ca3a6b19f4a2c2
                                                Module libmount.so.1 with build-id 4436aeea0cd8c01b5a77969e0531184f8b3513ce
                                                Module libtiff.so.5 with build-id 9e8868622f8b7144fd82dabfa8ac2fcaf6d45a34
                                                Module libjpeg.so.8 with build-id 8e6d3f3e8f438912b561c43b6e7f66e6e5e097d0
                                                Module libgmodule-2.0.so.0 with build-id 3b42a54783f0665e688370b6c57238c05822c50e
                                                Module libpixman-1.so.0 with build-id d2170a3ac106c2a68597bf7910ab04b1cdd69c14
                                                Module libxcb-shm.so.0 with build-id 828fec4d856e2710e732ea8d92c3f250c807b1c2
                                                Module libxcb-render.so.0 with build-id b1ca498d665807ab0ccdafbe8070853efd058173
                                                Module libxcb.so.1 with build-id 13d677412a71468381b11092915d231f664d18d3
                                                Module libXrender.so.1 with build-id 42e386d2acf3cde61081959d9671ca74acfb3edc
                                                Module libfreetype.so.6 with build-id f89dd5502e75aca28fb5c3ccd0dbd26fe822bfef
                                                Module libpng16.so.16 with build-id 2dc0bce07f199bf983c07a05fb95a6f4af83a9b3
                                                Module libz.so.1 with build-id fefe3219a96d682ec98fcfb78866b8594298b5a2
                                                Module libthai.so.0 with build-id a7ac5010b4275c49308021200d23690533952702
                                                Module libfribidi.so.0 with build-id fe9f35ac2a0074108c8306c517793f7279bd9b37
                                                Module libfontconfig.so.1 with build-id 36be6951b8c1e42a7dd05684a37400fc8ef9147c
                                                Module libharfbuzz.so.0 with build-id c58fe082cbde02fc176e3c3663a6d81386eb5027
                                                Module libpangoft2-1.0.so.0 with build-id c2c09f789578900f61b7fca4a4311d8b94d9a750
                                                Module ld-linux-x86-64.so.2 with build-id fc93487393eea02b5bc6e76e48976fc325294c24
                                                Module libc.so.6 with build-id 388993b6ef62f964bc7bf473c069fbfe957b9e44
                                                Module libwayland-cursor.so.0 with build-id 647d92328111682fb15bff1c20a4c9368414857c
                                                Module libwayland-client.so.0 with build-id 95e7368b400dd57e3db2a5c385de71c7dca08879
                                                Module libglib-2.0.so.0 with build-id f1d15261ce1317b9003a1f0957d5a528d063f630
                                                Module libgobject-2.0.so.0 with build-id a7dfc5c24acdbd0bcc40e3a427f917f679eef0d1
                                                Module libgio-2.0.so.0 with build-id bc795ed533f1b5c20cdc8600cf855216d692087f
                                                Module libgdk_pixbuf-2.0.so.0 with build-id 5b8422ab971b1a8a8e1c43b88738d4ee217f609e
                                                Module libXss.so.1 with build-id a3b819a932d6eb2b4fbfd0c6bd77242ef14e7366
                                                Module libXrandr.so.2 with build-id 154e55f082ee9e685d0794c98c5b76ffe9c8868e
                                                Module libXext.so.6 with build-id 17beadf1cb40d41ab36629db3b4eed74110678a7
                                                Module libXinerama.so.1 with build-id 8198240259261b612189e89c9fcfc902b025b382
                                                Module libX11.so.6 with build-id d8e0be8e0323aa421366f19065ecd1c76405c130
                                                Module libcairo.so.2 with build-id a222d042e56108d2786ece7bf291b56ba2069591
                                                Module libpango-1.0.so.0 with build-id 7e27c1e46a1d958f6b16e1ba199f8bdb3f100566
                                                Module libpangocairo-1.0.so.0 with build-id b65f507d9e33adfbd19369acef5e5a0a2422c6d1
                                                Module libm.so.6 with build-id 210ec9905e41825671210f8f7d0b24d6c371196a
                                                Module dunst with build-id 928820d1d28ffc8d594a11a00e617d9f9b72995b
                                                Stack trace of thread 372812:
                                                #0  0x00007efdca17d855 g_logv (libglib-2.0.so.0 + 0x5d855)
                                                #1  0x00007efdca17dad4 g_log (libglib-2.0.so.0 + 0x5dad4)
                                                #2  0x0000562cc0eea07d n/a (dunst + 0x1607d)
                                                #3  0x0000562cc0ee18dc n/a (dunst + 0xd8dc)
                                                #4  0x00007efdc9e29290 n/a (libc.so.6 + 0x29290)
                                                #5  0x00007efdc9e2934a __libc_start_main (libc.so.6 + 0x2934a)
                                                #6  0x0000562cc0ee1d05 n/a (dunst + 0xdd05)
                                                
                                                Stack trace of thread 372815:
                                                #0  0x00007efdca193f37 n/a (libglib-2.0.so.0 + 0x73f37)
                                                #1  0x00007efdca19584e g_slice_alloc (libglib-2.0.so.0 + 0x7584e)
                                                #2  0x00007efdca1712c1 g_source_new (libglib-2.0.so.0 + 0x512c1)
                                                #3  0x00007efdca3521a1 g_socket_create_source (libgio-2.0.so.0 + 0x941a1)
                                                #4  0x00007efdca3cd993 n/a (libgio-2.0.so.0 + 0x10f993)
                                                #5  0x00007efdca3cda89 n/a (libgio-2.0.so.0 + 0x10fa89)
                                                #6  0x00007efdca3cdb42 n/a (libgio-2.0.so.0 + 0x10fb42)
                                                #7  0x00007efdca174c6b g_main_context_dispatch (libglib-2.0.so.0 + 0x54c6b)
                                                #8  0x00007efdca1cb001 n/a (libglib-2.0.so.0 + 0xab001)
                                                #9  0x00007efdca1741cf g_main_loop_run (libglib-2.0.so.0 + 0x541cf)
                                                #10 0x00007efdca3c695c n/a (libgio-2.0.so.0 + 0x10895c)
                                                #11 0x00007efdca1a4405 n/a (libglib-2.0.so.0 + 0x84405)
                                                #12 0x00007efdc9e8c54d n/a (libc.so.6 + 0x8c54d)
                                                #13 0x00007efdc9f11b14 __clone (libc.so.6 + 0x111b14)
                                                
                                                Stack trace of thread 372813:
                                                #0  0x00007efdc9f05faf __poll (libc.so.6 + 0x105faf)
                                                #1  0x00007efdca1caf68 n/a (libglib-2.0.so.0 + 0xaaf68)
                                                #2  0x00007efdca172392 g_main_context_iteration (libglib-2.0.so.0 + 0x52392)
                                                #3  0x00007efdca1723e2 n/a (libglib-2.0.so.0 + 0x523e2)
                                                #4  0x00007efdca1a4405 n/a (libglib-2.0.so.0 + 0x84405)
                                                #5  0x00007efdc9e8c54d n/a (libc.so.6 + 0x8c54d)
                                                #6  0x00007efdc9f11b14 __clone (libc.so.6 + 0x111b14)
                                                
                                                Stack trace of thread 372814:
                                                #0  0x00007efdca15fd11 g_hash_table_remove (libglib-2.0.so.0 + 0x3fd11)
                                                #1  0x00007efdca1bf50b g_variant_type_info_unref (libglib-2.0.so.0 + 0x9f50b)
                                                #2  0x00007efdca1bf66f g_variant_unref (libglib-2.0.so.0 + 0x9f66f)
                                                #3  0x00007efdca3c241a g_dbus_message_to_blob (libgio-2.0.so.0 + 0x10441a)
                                                #4  0x00007efdca3b5b54 n/a (libgio-2.0.so.0 + 0xf7b54)
                                                #5  0x00007efdca3b62fd n/a (libgio-2.0.so.0 + 0xf82fd)
                                                #6  0x00007efdca3b64ec g_dbus_connection_send_message_with_reply (libgio-2.0.so.0 + 0xf84ec)
                                                #7  0x00007efdca3b677f g_dbus_connection_send_message_with_reply_sync (libgio-2.0.so.0 + 0xf877f)
                                                #8  0x00007efdca3c4257 n/a (libgio-2.0.so.0 + 0x106257)
                                                #9  0x00007efdca3c44c7 g_dbus_connection_call_sync (libgio-2.0.so.0 + 0x1064c7)
                                                #10 0x00007efdca3b7166 n/a (libgio-2.0.so.0 + 0xf9166)
                                                #11 0x00007efdca2fe683 n/a (libgio-2.0.so.0 + 0x40683)
                                                #12 0x00007efdca36621c n/a (libgio-2.0.so.0 + 0xa821c)
                                                #13 0x00007efdca1a75e3 n/a (libglib-2.0.so.0 + 0x875e3)
                                                #14 0x00007efdca1a4405 n/a (libglib-2.0.so.0 + 0x84405)
                                                #15 0x00007efdc9e8c54d n/a (libc.so.6 + 0x8c54d)
                                                #16 0x00007efdc9f11b14 __clone (libc.so.6 + 0x111b14)
                                                ELF object binary architecture: AMD x86-64

Jun 05 16:59:33 HOSTNAME systemd[456]: dunst.service: Main process exited, code=dumped, status=5/TRAP Jun 05 16:59:33 HOSTNAME systemd[456]: dunst.service: Failed with result 'core-dump'. Jun 05 16:59:33 HOSTNAME systemd[456]: Failed to start Dunst notification daemon.

[Vladimir-csp]

Xdg autostart could probably work and you're free to use it and document your usage for other people. I don't think dunst needs to implement something for that.

Just providing a proper /etc/xdg/autostart/dunst.desktop would solve this, dunst will be started by DE or any XDG-compliant session scripts, and not by systemd, potentially outside graphical session.

example

[Desktop Entry]
Name=Dunst
Comment=Shows desktop notifications
GenericName=Notification daemon
Exec=dunst
Terminal=false
Type=Application
Categories=Application;Utility;
Keywords=notifications;libnotify;

[LeCodingWolfie]

@U1s2e3r4n5a6m7e Besides the warning given by dunst on the missing folder icon on your case; the daemon error ("Couldn't initialize X11 output", now reported at #1095) might be solved by either running:

systemctl --user import-environment DISPLAY

or through this other solution, and alike; all of which worked for me to solve that same issue.

[U1s2e3r4n5a6m7e]

I solved the issue with this comment back in the day. Thanks @LeCodingWolfie

[C0D3D3V]

I have now also tested pretty much every suggestion from here and in various other issues that all are about the same topic.

Since using SDDM as a display manager, the dunst service also starts way too early for me and with each suggestion I tested, I got a variation of errors. Most recently I got a similar error as in https://github.com/dunst-project/dunst/issues/866:

 142   │ ERROR: [  get_x11_output:0065] Couldn't initialize X11 output. Aborting...
 143   │ Invalid MIT-MAGIC-COOKIE-1 key
 144   │ WARNING: Cannot open X11 display.
 145   │ ERROR: [  get_x11_output:0065] Couldn't initialize X11 output. Aborting...
 146   │ Invalid MIT-MAGIC-COOKIE-1 key

If I start dunst while i3 is already running then there is no problem, the same way I can just then restart the service and it works. However, this did not work directly in the i3 config as autostart. Finally I decided for the following solution:

I disabled the dunst service, then I simply created a script under ~/.config/i3/keep_up_dunst.py, which I put into the autostart exec --no-startup-id "~/.config/i3/keep_up_dunst.py". This is to keep dunst always running (I also had problems before where dunst just crashed, this also helps against that :D)

This is my script I'm using, feel free to modify and using it :D

#!/usr/bin/env python

import os
import time

from datetime import datetime

import psutil


def check_if_process_is_running(process_name):
    for proc in psutil.process_iter():
        try:
            if process_name.lower() in proc.name().lower():
                return True
        except (psutil.NoSuchProcess, psutil.AccessDenied, psutil.ZombieProcess):
            pass
    return False


LOG_PATH = '~/.dunst_log.txt'
full_log_path = os.path.expanduser(LOG_PATH)
if os.path.isfile(full_log_path):
    log_file_size = os.path.getsize(full_log_path)
    if log_file_size > 20000:
        os.remove(full_log_path)

time.sleep(0.1)
while True:
    if not check_if_process_is_running('dunst'):
        with open(full_log_path, 'a+', encoding='utf-8') as fs:
            fs.write(f'Starting dunst at: {datetime.now()}\n')
        os.system(f"dunst --config ~/.config/dunst/dunstrc >> {LOG_PATH} 2>&1")
    time.sleep(3)

[Linux-NDOB]

Arch Linux, AUR i3-gapps package.

Hello, my comment may be useless for a lot but useful for some others. I had the same problem exposed here and the only solution y found was to exit from i3 and log again.

I set too the command for start dunst on login in the i3 config file before exit and login again on i3-gaps and is working all fine, CTRL + R does not work, exit and login again worked for me.

[bynect]

Was this solved in the end?