Dunst crashes and dumps core when no X server is available

[pmattern]

If Dunst is launched in a context where it can't access an X server or Wayland, it crashes and dumps core right away.

This may e. g. happen in a virtual terminal session while X isn't running or when Dunst is launched by root on a system where X is run by a regular user.
Obviously, neither is an expected use case, but in particular the former can happen by incident rather quickly.
So all in all I think it would be good, if Dunst handled this situation a bit more gracefully.

Steps to reproduce:

• Make sure that Dunst is the only notification daemon around and a tool to track core dumps is available, e. g. systemd-coredump.
• Have a regular user issue an arbitrary invocation of notify-send on a virtual terminal while no X server or other windowing system is running.
• Check the core dump log. Will be similar to

Jul 28 18:58:12 desktop-1 systemd[12638]: Created slice User Core Session Slice.
Jul 28 18:58:12 desktop-1 systemd[12638]: Starting D-Bus User Message Bus...
Jul 28 18:58:12 desktop-1 systemd[12638]: Started D-Bus User Message Bus.
Jul 28 18:58:12 desktop-1 dbus-daemon[12662]: [session uid=1000 pid=12662] Activating systemd to hand-off: service name='org.freedesktop.Notifications' unit='dunst.service' requested by ':1.0' (uid=1000 pid=12660 comm="notify-send --app-name=notify-send CLI Tests zu Du")
Jul 28 18:58:12 desktop-1 dbus-daemon[12662]: [session uid=1000 pid=12662] Successfully activated service 'org.freedesktop.systemd1'
Jul 28 18:58:12 desktop-1 systemd[12638]: Starting Dunst notification daemon...
Jul 28 18:58:12 desktop-1 dunst[12664]: WARNING: Cannot open X11 display.
Jul 28 18:58:12 desktop-1 kernel: show_signal: 6 callbacks suppressed
Jul 28 18:58:12 desktop-1 kernel: traps: dunst[12664] trap int3 ip:7fdc62b26855 sp:7ffe6dbbe590 error:0 in libglib-2.0.so.0.7200.3[7fdc62ae6000+92000]
Jul 28 18:58:12 desktop-1 kernel: audit: type=1701 audit(1659027492.933:174): auid=1000 uid=1000 gid=1000 ses=8 pid=12664 comm="dunst" exe="/usr/bin/dunst" sig=5 res=1
Jul 28 18:58:12 desktop-1 audit[12664]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=8 pid=12664 comm="dunst" exe="/usr/bin/dunst" sig=5 res=1
Jul 28 18:58:12 desktop-1 dunst[12664]: ERROR: [  get_x11_output:0065] Couldn't initialize X11 output. Aborting...
Jul 28 18:58:12 desktop-1 systemd[1]: Created slice Slice /system/systemd-coredump.
Jul 28 18:58:12 desktop-1 audit: BPF prog-id=39 op=LOAD
Jul 28 18:58:12 desktop-1 audit: BPF prog-id=40 op=LOAD
Jul 28 18:58:12 desktop-1 audit: BPF prog-id=41 op=LOAD
Jul 28 18:58:12 desktop-1 kernel: audit: type=1334 audit(1659027492.970:175): prog-id=39 op=LOAD
Jul 28 18:58:12 desktop-1 kernel: audit: type=1334 audit(1659027492.970:176): prog-id=40 op=LOAD
Jul 28 18:58:12 desktop-1 kernel: audit: type=1334 audit(1659027492.970:177): prog-id=41 op=LOAD
Jul 28 18:58:12 desktop-1 kernel: audit: type=1130 audit(1659027492.973:178): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-12668-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 28 18:58:12 desktop-1 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-12668-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 28 18:58:12 desktop-1 systemd[1]: Started Process Core Dump (PID 12668/UID 0).
Jul 28 18:58:13 desktop-1 systemd[12638]: Starting Monitoring core dumps :: *.service...
Jul 28 18:58:13 desktop-1 systemd-coredump[12669]: Process 12664 (dunst) of user 1000 dumped core.
                                                      
                                                      Module linux-vdso.so.1 with build-id a5290dd75cb1eb0fb20c7a46c6fa011045892af5
                                                      Module libbrotlicommon.so.1 with build-id acfd597a977c8087bb6184383daae2e828a9ce42
                                                      Module libpthread.so.0 with build-id 95ae4f30a6f12ccbff645d30f8e1a3ee23ec7d36
                                                      [...]

I took the liberty to quickly post the logs without debug symbols enabled as the problem seems to be 100% and easily reproducible. If you do need an output with debug symbols enabled, just let me know.

1ef38e5 on Arch Linux x86_64 per AUR package dunst-git.

[LeCodingWolfie]

I did also have the same issue, though I am using the release version of dunst package, and also using Wayland as the main desktop environment through Hyprland as WM. Even more, running dunst-related (dunstify example as per the Wiki introduction) command results in:

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

Trying to restart the daemon shows a similar error and dump.

Anyways, looking for issues with that headline, an issue of which referred "duplicate" by bebehei, can be solved by running:

systemctl --user import-environment DISPLAY

In fact, I just ran with the issue that a dunst process was running while trying to restart the dunst daemon:

CRITICAL: [dbus_cb_name_lost:1044] Cannot acquire 'org.freedesktop.Notifications': Name is acquired by 'dunst' with PID '96228'.

which I killed, and could restart the daemon back, and could run dunstify example.

Now, it's only showing this warning for me (which, by the way, has been previously reported on support on Wayland):

Xlib: extension "MIT-SCREEN-SAVER" missing on display ":0".

Using this similar solution may also help to solve the problem.

^{By the way, running dunst doesn't output anything, I don't know if it's an actual issue; though it might just start/enable the daemon if it isn't running (see)}

[antaz]

importing $WAYLAND_DISPLAY=wayland-0 fixed the crash for me.

This can also be noted as "wrong XScreen." I find Dunst will core dump and hang something terrible if the calling script/application is on another XScreen which is super frustrating.

May 23 19:49:46 $HOSTNAME systemd[18642]: Starting Dunst notification daemon...
May 23 19:49:46 $HOSTNAME dunst[3074577]: WARNING: Cannot open X11 display.
May 23 19:49:46 $HOSTNAME dunst[3074577]: ERROR: [  get_x11_output:0065] Couldn't initialize X11 output. Aborting...
May 23 19:49:46 $HOSTNAME kernel: traps: dunst[3074577] trap int3 ip:7efd5feea9a5 sp:7fff048ff950 error:0 in libglib-2.0.so.0.7600.2[7efd5feaa000+9d000]
May 23 19:49:46 $HOSTNAME systemd[1]: Started Process Core Dump (PID 3074582/UID 0).
May 23 19:49:46 $HOSTNAME systemd-coredump[3074583]: [🡕] Process 3074577 (dunst) of user 1000 dumped core.
                                                  
                                                  Stack trace of thread 3074577:
                                                  #0  0x00007efd5feea9a5 g_logv (libglib-2.0.so.0 + 0x5e9a5)
                                                  #1  0x00007efd5feeac64 g_log (libglib-2.0.so.0 + 0x5ec64)
                                                  #2  0x0000555e67d7a39d n/a (dunst + 0x1439d)
                                                  #3  0x0000555e67d738c1 n/a (dunst + 0xd8c1)
                                                  #4  0x00007efd5fca9850 n/a (libc.so.6 + 0x23850)
                                                  #5  0x00007efd5fca990a __libc_start_main (libc.so.6 + 0x2390a)
                                                  #6  0x0000555e67d73ce5 n/a (dunst + 0xdce5)
                                                  
                                                  Stack trace of thread 3074578:
                                                  #0  0x00007efd5fd892ed syscall (libc.so.6 + 0x1032ed)
                                                  #1  0x00007efd5ff3c7b5 g_cond_wait (libglib-2.0.so.0 + 0xb07b5)
                                                  #2  0x00007efd5feb0fb4 n/a (libglib-2.0.so.0 + 0x24fb4)
                                                  #3  0x00007efd5ff17f9e n/a (libglib-2.0.so.0 + 0x8bf9e)
                                                  #4  0x00007efd5ff13315 n/a (libglib-2.0.so.0 + 0x87315)
                                                  #5  0x00007efd5fd0d44b n/a (libc.so.6 + 0x8744b)
                                                  #6  0x00007efd5fd90e40 n/a (libc.so.6 + 0x10ae40)
                                                  
                                                  Stack trace of thread 3074581:
                                                  #0  0x00007efd5fd83c0f __poll (libc.so.6 + 0xfdc0f)
                                                  #1  0x00007efd5ff4317f n/a (libglib-2.0.so.0 + 0xb717f)
                                                  #2  0x00007efd5fee5c7f g_main_loop_run (libglib-2.0.so.0 + 0x59c7f)
                                                  #3  0x00007efd60148d3c n/a (libgio-2.0.so.0 + 0x10ed3c)
                                                  #4  0x00007efd5ff13315 n/a (libglib-2.0.so.0 + 0x87315)
                                                  #5  0x00007efd5fd0d44b n/a (libc.so.6 + 0x8744b)
                                                  #6  0x00007efd5fd90e40 n/a (libc.so.6 + 0x10ae40)
                                                  
                                                  Stack trace of thread 3074580:
                                                  #0  0x00007efd5fd83c0f __poll (libc.so.6 + 0xfdc0f)
                                                  #1  0x00007efd5ff4317f n/a (libglib-2.0.so.0 + 0xb717f)
                                                  #2  0x00007efd5fee5c7f g_main_loop_run (libglib-2.0.so.0 + 0x59c7f)
                                                  #3  0x00007efd601386bc g_dbus_connection_send_message_with_reply_sync (libgio-2.0.so.0 + 0xfe6bc)
                                                  #4  0x00007efd60144837 n/a (libgio-2.0.so.0 + 0x10a837)
                                                  #5  0x00007efd60144aa7 g_dbus_connection_call_sync (libgio-2.0.so.0 + 0x10aaa7)
                                                  #6  0x00007efd60139150 n/a (libgio-2.0.so.0 + 0xff150)
                                                  #7  0x00007efd6007bbd3 n/a (libgio-2.0.so.0 + 0x41bd3)
                                                  #8  0x00007efd600e621c n/a (libgio-2.0.so.0 + 0xac21c)
                                                  #9  0x00007efd5ff189a3 n/a (libglib-2.0.so.0 + 0x8c9a3)
                                                  #10 0x00007efd5ff13315 n/a (libglib-2.0.so.0 + 0x87315)
                                                  #11 0x00007efd5fd0d44b n/a (libc.so.6 + 0x8744b)
                                                  #12 0x00007efd5fd90e40 n/a (libc.so.6 + 0x10ae40)
                                                  
                                                  Stack trace of thread 3074579:
                                                  #0  0x00007efd5fd83c0f __poll (libc.so.6 + 0xfdc0f)
                                                  #1  0x00007efd5ff4317f n/a (libglib-2.0.so.0 + 0xb717f)
                                                  #2  0x00007efd5fee51a2 g_main_context_iteration (libglib-2.0.so.0 + 0x591a2)
                                                  #3  0x00007efd5fee51f2 n/a (libglib-2.0.so.0 + 0x591f2)
                                                  #4  0x00007efd5ff13315 n/a (libglib-2.0.so.0 + 0x87315)
                                                  #5  0x00007efd5fd0d44b n/a (libc.so.6 + 0x8744b)
                                                  #6  0x00007efd5fd90e40 n/a (libc.so.6 + 0x10ae40)
                                                  ELF object binary architecture: AMD x86-64
May 23 19:49:46 $HOSTNAME systemd[18642]: dunst.service: Main process exited, code=dumped, status=5/TRAP
May 23 19:49:46 $HOSTNAME systemd[18642]: dunst.service: Failed with result 'core-dump'.
May 23 19:49:46 $HOSTNAME systemd[1]: systemd-coredump@4-3074582-0.service: Deactivated successfully.
May 23 19:49:46 $HOSTNAME systemd[18642]: Failed to start Dunst notification daemon.

[bynect]

the core dump is a direct consequence of calling LOG_E(). My question now is, how should we handle this gracefully? Exit with a message? Or wait for a x screen to be set up?

Not sure what you mean by "wait for an XScreen to be set up" when there are already many. In may case it's not because I'm running Wayland, in my case it's because it's assuming to run on XScreen 0.0 but then called on 0.1 or 0.2. My use case is slowly being killed by the "Wayland future proofing" but Waylands design (at present) breaks by design my hardware config.

However I'd be more likely to vote on exit with a message on start. Waiting for some requirement gives the false illusion things are functioning and the user may continue one assuming things will work.

[bynect]

Not sure what you mean by "wait for an XScreen to be set up" when there are already many. In may case it's not because I'm running Wayland, in my case it's because it's assuming to run on XScreen 0.0 but then called on 0.1 or 0.2. My use case is slowly being killed by the "Wayland future proofing" but Waylands design (at present) breaks by design my hardware config.

sorry, I meant that if the x screen is not found to wait for one

However I'd be more likely to vote on exit with a message on start. Waiting for some requirement gives the false illusion things are functioning and the user may continue one assuming things will work.

Yes you are totally right and I think this is the right course of action

Maybe the solution could be as easy as changing the LOG_E with DIE (which exits instead of abort)

I'm guessing from this Dunst will simply not work for me going forward then since it will by design bail rather than just run on the XScreen it's being called from?

[bynect]

I'm guessing from this Dunst will simply not work for me going forward then since it will by design bail rather than just run on the XScreen it's being called from?

If it works now, it will work in the future. I am only talking about using exit instead of abort when reporting the error, so the behavior is not changed

It doesn't work now which is why I have my above report. Well it works but ONLY on one XScreen. If anything calls it from another XScreen it just dies.

May 23 19:49:46 $HOSTNAME dunst[3074577]: WARNING: Cannot open X11 display.
May 23 19:49:46 $HOSTNAME dunst[3074577]: ERROR: [  get_x11_output:0065] Couldn't initialize X11 output. Aborting...
May 23 19:49:46 $HOSTNAME kernel: traps: dunst[3074577] trap int3 ip:7efd5feea9a5 sp:7fff048ff950 error:0 in libglib-2.0.so.0.7600.2[7efd5feaa000+9d000]
May 23 19:49:46 $HOSTNAME systemd[1]: Started Process Core Dump (PID 3074582/UID 0).
May 23 19:49:46 $HOSTNAME systemd-coredump[3074583]: [🡕] Process 3074577 (dunst) of user 1000 dumped core.

***Wait, I semi retract this! Kinda...maybe...let me explain.

I just did a test since this bug report is pretty old. Seems something has "half" fixed it. So if it's called with an explicitly defined XScreen it no longer crashes (which is good) but dunst can still only run on and notify on one XScreen.

[bynect]

It doesn't work now which is why I have my above report. Well it works but ONLY on one XScreen. If anything calls it from another XScreen it just dies.

This is the code that opens the display (using xlib) and the only thing where it could fail to initialize like you see.

        if (!(xctx.dpy = XOpenDisplay(NULL))) {
                LOG_W("Cannot open X11 display.");
                return false;
        }

this is an excerpt from the xlib documentation

On a POSIX-conformant system, if the display_name is NULL, it defaults to the value of the DISPLAY environment variable

Thus, dunst is simply trying to open the default display with XOpenDisplay and a NULL.
This will open the DISPLAY env var. Thus theoretically if you defined DISPLAY correctly this could be solved

I saw the edit.
The reason that dunst can run only on one display is at the moment by design. Because we open a single X connection/display. to run on multiple display would mean changing a lot of the X11 code. So if you want to switch between displays I think you have to kill dunst and reopen it with the correct DISPLAY set. Which is annoying but dunst can be simply reloaded by killing it

Gotcha, I'm just glad it doesn't crash when called from a different XScreen any longer. Back when I chimed in on this bug report if I launched dunst on say XScreen 0.1 but then an application on XScreen 0.2 did a notification blam, crash. Testing today I see calls actually work. I had removed a lot of notification stuff from my scripts and tried to silence applications that used it because it just killed the dunst server all the time and only allowed things I knew wouldn't cause the crash.

[bynect]

Gotcha, I'm just glad it doesn't crash when called from a different XScreen any longer. Back when I chimed in on this bug report if I launched dunst on say XScreen 0.1 but then an application on XScreen 0.2 did a notification blam, crash. Testing today I see calls actually work. I had removed a lot of notification stuff from my scripts and tried to silence applications that used it because it just killed the dunst server all the time and only allowed things I knew wouldn't cause the crash.

Well, I'm glad you solved in the end. If during the refactoring of the x11 backend I can add multiple server support I might do so, who knows 😁

Heh well I know myself a few others would probably dig that but seems nuts like me are a dying breed. Maybe XCB would make that easier? (if the documentation doesn't make it harder hah) Running Multi GPU that is. Or perhaps I should say most multi GPU setups these days are one for output the others for ML / Cuda workloads so they don't care if they are X or Wayland. For those like me who run several screens per GPU Wayland is a death knell unless they fundamentally change how multi GPU works.

[bynect]

Heh well I know myself a few others would probably dig that but seems nuts like me are a dying breed. Maybe XCB would make that easier? (if the documentation doesn't make it harder hah) Running Multi GPU that is. Or perhaps I should say most multi GPU setups these days are one for output the others for ML / Cuda workloads so they don't care if they are X or Wayland. For those like me who run several screens per GPU Wayland is a death knell unless they fundamentally change how multi GPU works.

Yes, using multiple xorg sessions on the same gpu is not something you hear frequently. I am kinda curios, would you mind sharing why/what advantages it has?

Also now that you said xcb, I actually worked with it on another project. so maybe instead of rewriting the xlib backend I can make a xcb backend 🤔

I'm not running multiple xorg instances/seats, just a single xorg instance with each GPU given their own XScreen.

If I try to TL;DR the "advantage" of this, giving each GPU/"device" their own XScreen ensures every GPU gets 100% of their performance/resources and applications can be denoted to work on that single GPU and its screens.

The mid version is rather literally every other configuration option is terrible for multiGPU. GPU's sit at idle around 50% with Xinerama or xrandr provider setups. High heat/power waste, worthless performance. Wayland actually makes things the worst. (Mayish 2023 there was some news about this being addressed but updates have been sparse.) All other configs however work around lumping things together which ends up with a "lowest common denominator" issue for unmatched GPU's and even when matched there is horrendous overhead.