Reload config by SIGUSR1

[nick87720z]

I found such feature in tint2, with at least one use case at tint2conf which does it on config save. Not sure if it's more effective than e.g. direct use of inotify. Auto-reload on file change could be done by separate tools like fsniper.

[tsipinakis]

This has been requested before (#63) however, dunst was built around the assumption that the settings struct is never modified so adding that would require a rework of some other areas of the code.

Additionally, SIGUSR1 is already taken by the pause command, so it'll probably have to go into dunstctl as dunstctl reload or something similar.

[tangxinfa]

If dunst supported reload, we can switch theme dynamically.

On my desktop, i exported colors from current emacs theme, and apply it to polybar, rofi, dunst. But restart dunst will have the risky of lose notifications.

[pbrisbin]

I would love to see this feature.

dunst was built around the assumption that the settings struct is never modified so adding that would require a rework of some other areas of the code.

I haven't looked at the code, but when polybar receives SIGUSR1 to reload config, its output seems to indicate that it replaces its own process with a new one, rather than actually "reloading config" (it shows exactly the same shutting down and starting up messages). Would that be an easier approach that doesn't require making the settings struct mutable?

Additionally, SIGUSR1 is already taken by the pause command, so it'll probably have to go into dunstctl as dunstctl reload or something similar.

I don't mind a dunstctl command for this, but I wanted to mention SIGUSR2 as another option.

[fwsmit]

I would love to see this feature.

Note that currently you can restart dunst perfectly fine by killing it and letting it autostart again. You can also systemctl restart dunst if you use systemd. The only thing is that your notification history is lost.

dunst was built around the assumption that the settings struct is never modified so adding that would require a rework of some other areas of the code.

I don't expect this to be a big problem. Most of the settings struct will be perfectly fine with being modified.

I haven't looked at the code, but when polybar receives SIGUSR1 to reload config, its output seems to indicate that it replaces its own process with a new one, rather than actually "reloading config" (it shows exactly the same shutting down and starting up messages). Would that be an easier approach that doesn't require making the settings struct mutable?

This is already possible without it being built into dunst. A proper reload should at least save the notification history. This would be easiest when the same process is kept.

Additionally, SIGUSR1 is already taken by the pause command, so it'll probably have to go into dunstctl as dunstctl reload or something similar.

I don't mind a dunstctl command for this, but I wanted to mention SIGUSR2 as another option.

SIGUSR2 is already being used for unpausing.

[nick87720z]

Note that currently you can restart dunst perfectly fine by killing it and letting it autostart again. You can also systemctl restart dunst if you use systemd. The only thing is that your notification history is lost.

I use this wrapper for all session services:

#!/bin/sh

while true; do
    ${@}
done

Additionally, SIGUSR1 is already taken by the pause command, so it'll probably have to go into dunstctl as dunstctl reload or something similar.

I don't mind a dunstctl command for this, but I wanted to mention SIGUSR2 as another option.

SIGUSR2 is already being used for unpausing.

Would be more logical to use same signal to toggle, though then there must be feedback. Also - could not si_value from siginfo be used, with properly set SA_SIGINFO? This is from posix manual, though not linux specific, though I failed to find way to specify value in shell kill command.

[fwsmit]

I've thrown together a quick proof of concept in https://github.com/dunst-project/dunst/pull/968. Please let me know if a setting you want to change doesn't get covered by this reload. There are still a few bugs, but I'll fix them once I know what the cause is.

[haselwarter]

Bump. It's 2023, I want to dynamically switch between light and dark colour schemes without losing my history :)

[LamprosPitsillos]

Bump x 2 . I would also like to see this feature , thanks for the great work!

[fwsmit]

Please don't bump issues. If you want that it is implemented you can take a look at my proof of concept (#968) and try to improve on the bugs it introduced. I will try to take a look at it if you submit a proposal or PR (see #1117 for why)