Dunst crashes and dumps core when no X server is available #1095
Comments
|
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 (
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:
In fact, I just ran with the issue that a dunst process was running while trying to restart the dunst daemon:
which I killed, and could restart the daemon back, and could run Now, it's only showing this warning for me (which, by the way, has been previously reported on support on Wayland):
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) |
|
importing |
|
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. |
|
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. |
sorry, I meant that if the x screen is not found to wait for one
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? |
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. ***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. |
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
Thus, dunst is simply trying to open the default display with XOpenDisplay and a NULL. I saw the edit. |
|
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. |
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. |
|
Same here: -❯ echo $WAYLAND_DISPLAY Linux nixos 6.6.26 1-NixOS SMP PREEMPT_DYNAMIC Wed Apr 10 14:36:08 UTC 2024 x86_64 GNU/Linux -❯ dunst --version |
Wait, are you trying to run dunst on wayland and it crashes because there is no X server?? |
|
@bynect Yea I was getting the same errors as mentioned above. It's working fine now. I'm fairly new to |
I thought that this was fixed before, I will check again |
|
UPDATE: So the fix is to add The only issue now is I get this when running: journalctl --user -xeu dunst.serviceMore than likely dunst would have to be built without X11 support if you're using wayland. Here is the full working script for nixos using a window manager. [Unit]
Description=Dunst notification daemon
Documentation=man:dunst(1)
PartOf=default.target
[Service]
# 04/17/2024 DISPLAY added for nixos. https://github.com/dunst-project/dunst/issues/1095#issuecomment-2061554769
Environment=DISPLAY=:0
Type=dbus
BusName=org.freedesktop.Notifications
ExecStart=/nix/store/f40mb54130x37xfkiqcilz0ylhd1klm4-dunst-1.10.0/bin/dunst
[Install]
WantedBy=default.targetYou may also need to do this in your window manager startup: dbus-update-activation-environment DISPLAY WAYLAND_DISPLAY |
Dunst should be able to understand that it is running on wayland by looking at the WAYLAND_DISPLAY even if it was built with xorg support. |
|
@bynect I'm getting |
I am not sure what you mean(?) Anyhow, dunst checks the WAYLAND_DISPLAY env var and if it is defined tries to use the wayland output (if it was compiled). It should not even try to use xorg on a wayland environment (unless force_xwayland is set to true). |
I meant the output of I think it's probably not a big deal since it's a screen saver issue, my main problem was resolved. Apr 17 11:36:38 nixos dunst[171679]: Xlib: extension "MIT-SCREEN-SAVER" missing on display ":0".I'm not familar with the nixos build of dunst but this link may be of interest. This is what comes by default |
I think that you should not export DISPLAY which is xorg specific when using wayland. I am not too sure what codepath dunst is taking at this point but it should not use Xorg things at all. This message is coming from some library trying to use xorg when there is no xorg. What happens if you pass only WAYLAND_DISPLAY? |
|
@bynect I think the solution would be to build dunst without XORG support but not sure I'm up for I don't know what you mean by: I started getting errors again but I just restart Which is not a big deal. |
Building dunst without Xorg support is a new feature (added in the latest release). The solution should be something else, since dunst should work with both compiled. Anyway, the DISPLAY env var is for Xorg and WAYLAND_DISPLAY is for wayland. Having both may lead to problems, especially if one is not used. This is why I asked what happens if you don't pass the DISPLAY var at all.
I suppose that that warning is due to the fact that despite passing the DISPLAY var no Xorg server is running. But I am not too sure how nixos manages environments. |
|
@bynect I took it off from my river |
|
UPDATE: I did get rid of the errors with "Environment="DISPLAY=:0" However, now I am getting this: Unable to send notification: Error calling StartServiceByName for org.freedesktop.Notifications: Process org.freedesktop.Notifications received signal 5Funny thing about it running "dusnt" directly from the terminal works. More than likely cause I have all my variables in the shell. FIX: I ended up starting dunst manually instead of with systemd. Perhaps there's something wrong with my config? [Unit]
Description=Dunst notification daemon
Documentation=man:dunst(1)
PartOf=default.target
[Service]
Environment="DISPLAY=:0"
Type=dbus
BusName=org.freedesktop.Notifications
ExecStart=/run/current-system/sw/bin/dunst
[Install]
WantedBy=default.target |
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:
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.
The text was updated successfully, but these errors were encountered: