won't implement
that would have been very handy :/
My workaround is to killall dunst;notify-send foo. Works fine on debian.
@knopwob: why not? Is something blocking this?
@knopwob: why not? Is something blocking this?
because the workaround posted above works good enough, IMHO.
@Eizen @tsipinakis your opinions? Feel free to reopen this issue, if you think otherwise.
A workaround has already been mentioned and I don't think reloading the configuration is something that needs to be done that often, so I'm not sure how useful implementing this will be.
That being said, I'd reopen this if there is a use-case that I haven't considered. @piahoo can you elaborate on why you need this feature?
How exactly does that work around work? That highly depends on how you're starting dunst. I for one do it with a simple: exec --no-startup-id dunst on my i3 config. With doesn't get executed when restarting i3 in place or reloading i3.
That makes reloading the dunst config quite annoying.
@tsipinakis
@luan From i3's documentation:
"if you need a command to run also when restarting i3 you should use the exec_always keyword"
You could easily use: exec_always --no-startup-id dunst as a workaround. Besides for any other use-case one could use a keybind with the previous workaround, in i3 for example: bindsym $mod+Shift+d --release exec --no-startup-id killall dunst;notify-send foo. So i don't really see a valid reason to implement this so far.
As @Eizen said. It's also expected that you're using the dbus service so that dunst starts automatically when a notification is sent. Is there any reason you're starting dunst manually @luan ?
As a workaround for now I am using sudo pkill dunst and then dunst -config ~/.config/dunst/dunstrc &
Edit (@bebehei): Please do not start dunst manually after killing it. DBus does a great service there and automatically restarts the programs. Use the "official workaround": killall dunst;notify-send foo
@Aeres-u99 It does not do a great service.
killall dunst does not work for me (I don't know what other program is being considered by D-Bus) and the Arch Wiki says:

@tsipinakis One reloads dunst every time they change configuration. I think that's often enough.
This could be added with #651 , when that's done.
The main problem here was that there was no way to send commands to dunst outside the normal notification API. With that this issue is resolved.
I don't know what other program is being considered by D-Bus
You can find out with:
grep -r Notifications /usr/share/dbus-1/services/
notify-send while Dunst is not open just hangs indefinitely. dbus does not automatically start dunst for me, even though grep -r Notifications /usr/share/dbus-1/services/ says ./usr/share/dbus-1/services/org.knopwob.dunst.service:Name=org.freedesktop.Notifications.
Most helpful comment
My workaround is to
killall dunst;notify-send foo. Works fine on debian.