If I edit dunstrc, dunst stops working

[juacq97]

Every time I change the colors on dunstrc, dunst stops working until I reboot the system. There's no error message. Even notify-send stops working.

Installation info

• Version: Dunst - A customizable and lightweight notification-daemon 1.5.0 (2020-07-23)
• Install type: Package manager
• Distro and version: Artix Linux

[fwsmit]

Does the dunst command give no error message either? Please try killing the current dunst process; pkill dunst and starting a new one with debug info enabled: dunst -verbosity debug. What message does it give then?

[juacq97]

If I kill dunst (even without change the config file), the notifications stops working. dunst --verbosity debug shows this:

󰧞 dunst -verbosity debug
DEBUG: RUN
DEBUG: XEvent: Ignoring '65'
DEBUG: XEvent: Checking for active screen changes
DEBUG: XEvent: Checking for active screen changes
DEBUG: XEvent: Checking for active screen changes
DEBUG: XEvent: Checking for active screen changes
DEBUG: XEvent: Checking for active screen changes
DEBUG: XEvent: Checking for active screen changes
DEBUG: XEvent: Checking for active screen changes
DEBUG: XEvent: Checking for active screen changes
DEBUG: XEvent: Checking for active screen changes
DEBUG: XEvent: Checking for active screen changes
DEBUG: XEvent: Checking for active screen changes
DEBUG: XEvent: Checking for active screen changes

I checked out with https://www.bennish.net/web-notifications.html to send notifications. I get "Notification #4 queued for display" every time I send a notification after killing dunst.

[juacq97]

I tried with the default config file too and the same happens

[fwsmit]

Notifications are sent through dbus. Artix linux doesn't use systemd (which normally provides dbus). This may be why you're having problems.

After starting dunst -verbosity debug, what is the output of dunstctl debug?

[juacq97]

$ dunstctl debug
Dunst is not running.

[bebehei]

I suspect, there is another (dysfunctional) Notification Manager running, started by either systemd or DBus.

Please use dunst -print to start dunst. So dunst will print the actual notification content.

Also another way to debug it, would be dbus-monitor path=/org/freedesktop/Notifications. This will print out all activity about FreeDesktop Notifications.

[juacq97]

Please use dunst -print to start dunst.

This command does nothing after killing dunst.

Also another way to debug it, would be dbus-monitor path=/org/freedesktop/Notifications

This is the output:

$ dbus-monitor path=/org/freedesktop/Notifications

signal time=1609391014.982327 sender=org.freedesktop.DBus -> destination=:1.11 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.11" #This "string" number changes every time I run the command by +0.01, the next time I run it it says 1.12, and after that, 1.13
signal time=1609391014.982348 sender=org.freedesktop.DBus -> destination=:1.11 serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost
   string ":1.11"

The only other notification manager I have is mako, a Wayland notification manager I use with sway, and works fine. Of course, I can't even run it from X11. I tried to uninstall it and run dunst again, but nothing happened

[bebehei]

Have you sent notifications with notify-send. It seems, that there are no notifications sent at all. You have to send notifications. (Otherwise dunst -print won't be able to print any notification data to prove, that it's the process receiving notifications).

#This "string" number changes every time I run the command by +0.01, the next time I run it it says 1.12, and after that, 1.13

Is this your comment? If so, the behavior you're commenting on is normal and logic from DBus.

[juacq97]

Have you sent notifications with notify-send.

I did it, and with the same web page to test notifications from the browser. notify-send doesn't works, even when dunst is "working"

[bebehei]

Well, the dbus-monitor clearly provides enough evidence, that there are no FDO-specific calls done.

This must be a dbus-related problem.

[bynect]

closing since this doesn't seem a problem from dunst