Closed nagisa closed 2 years ago
Thank you for the bug report! I have seen the same thing a couple times after running dunst for a while, but i dont do that often, so I haven't looked into it yet. I dont think th pause function is at fault here, but instead something wayland-specific.
There are a few things you can do to provide more debug information. The first is looking at what dunstctl count displayed
returns. I expect dunst will think it is displaying a notification.
The second is more likely to give some information. Try running dunst with WAYLAND_DEBUG=1
. This will show all wayland actions being performed, so we know if dunst is sending a surface out.
The third thing you can do is running the X11 version of dunst with force_xwayland=true
.
Thank you for your time and I hope we can fix this issue
A few more things to note: I do see comments on the mako issue saying that the git version works. It would be nice to know if that's the case. Furthermore, Dunst and mako are sharing quite some wayland code, so they might share some bugs as well.
Since some time I noticed this too. I'm running hikari. My deduction was, it had something to do with wlroots 0.15 and the compositor in question, as I did a git bisect on dunst back to the time where Wayland support was introduced and could always reproduce the problem. On how to reproduce: using it to show changes in the volume level. If I one at a time changed the volume level and waited for every notification to disappear everything was okay. But as soon as I didn't care about that, after the notification disappeared it wouldn't show up anymore
It might still be a bug present in the initial dunst wayland implementation. But since it has only been reproduced on sway afaik, it's only guessing at this point. The debug info mentioned above would probably narrow it down.
That may be, but then it only appeared with wlroots 0.15. This behaviour wasn't there with previous versions. And I use dunst and its wayland integration from the beginning. And as written: Can easily reproduce on a different compositor:
Log (fairly long, at the end were dunst doesn't appear anymore):
@Narrat could you please move the log of yours either to a gist or wrap it in
<details>
<summary>Logs</summary>
logs
</details>
?
So recently there have been a couple confirmations that switching to git mako helps with it not being able to show anything, anymore.
I have looked through the change history in mako and there aren't all that many changes to look through. https://github.com/emersion/mako/commit/6caaa557d1bb767a037b36bb294bcb78059fb2ba seems like the only relevant change.
These are the relevant-looking commits:
all pretty small, and all look like something dunst would want to integrate one way or another.
Thank you both for the investigation.
could you please move the log of yours either to a gist or wrap it in
Done
So recently there have been a couple confirmations that switching to git mako helps with it not being able to show anything, anymore.
If that's the case, that would be great, since dunst and mako have pretty much identical wayland implementations. I'll make a branch applying all the patches that have been made to mako's wayland file. When that's done, could you test it to see if that fixes it?
I've made a PR (#1067), although I'm sceptical this fixes the bug, since the first two patches are meant to fix am memory leak and the other applies to same-size reconfigures. But testing to see if it helps would be appreciated.
I also affected with this bug for sometime. I'll test the PR today
Has anyone noticed a difference with #1067?
I've been using the patch for four days uptime. The notifications are still showing up so far, which is good. Might need more tester though
I've merged #1067. If you see this problem again in current dunst-git or later, let me know and I'll reopen this issue.
Will also test a build from git when I'm around one of my systems. Which may take some time. Not that much around. Therefore thank you, fwsmit, for taking care of the suggestion made by nagisa to put the log into a collapsible.
FWIW for me the issue went away before I could apply the patch, so it might very well be the case that it was indeed an issue in some other component (sway or wlroots perhaps.)
As I could produce this behaviour frequently and now with a build from master not... It indeed seems to be fixed :)
Great!
I got this bug again with the latest dunst-git. Anyone else noticed it again?
Nvm, wrong issue. You can ignore the comment.
Issue description
I have recently switched from mako to dunst due to https://github.com/emersion/mako/issues/404, and dunst was working quite well for me until after a couple days of runtime
dunst
stopped showing notifications too!I'm not entirely sure at this point if this is an issue with dunst or sway (the wayland compositor I use), but I have been running both with debug logging enabled and was able to reproduce the issue just now.
When I run
notify-send -t5
, the following output fromdunstctl
is visible:That is – the dunst appears to be operating as usual.
However I don't see any notifications and sway's logs show no sign of any windows being created like for example these I otherwise would see when things work normally:
So in short, wayland surfaces aren't getting created, but dunst does not surface any errors in its own logs either.
I utilize
set-paused
functionality to stop notifications from showing up when the screen is locked, but runningdunstctl is-paused
returnsfalse
. Is there a reason to believe use of thepause
functionality could be to blame here?Any advise for further troubleshooting would be greatly appreciated
Installation info
I haven't attempted to minify the configuration yet.
dunstrc
```ini [global] sort = yes follow = mouse enable_posix_regex = true origin = bottom-right font = Source Code Pro Semibold 18 markup = yes format = "%a %s\n%b" layer = overlay alignment = left word_wrap = no indicate_hidden = yes frame_width = 5 width = (0, 1500) height = 500 separator_height = 2 padding = 20 horizontal_padding = 20 text_icon_padding = 10 vertical_alignment = top icon_size = 48 icon_theme = "Papirus-Dark" icon_position = left offset = 5x5 progress_bar_frame_width = 2 progress_bar_max_width = 1000 progress_bar_min_width = 500 progress_bar_height = 15 separator_color = "#93A1A1FF" frame_color = "#93A1A1A0" highlight = "#268BD2FF" background = "#002B36FF" corner_radius = 10 dmenu = /nix/store/vh0q0zzfvfdjxm6j5fa86mj1lbg4y33b-menu browser = gio open enable_recursive_icon_lookup = true [urgency_low] foreground = "#93A1A1FF" timeout = 10 [urgency_normal] foreground = "#93A1A1FF" timeout = 10 [urgency_critical] foreground = "#CB4B16FF" highlight = "#CB4B16FF" timeout = 0 [Quodlibet] desktop_entry = "quodlibet" icon_size = 256 # vim: ft=cfg ```