Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reload config by SIGUSR1 #719

Closed
nick87720z opened this issue May 29, 2020 · 10 comments
Closed

Reload config by SIGUSR1 #719

nick87720z opened this issue May 29, 2020 · 10 comments
Labels
Milestone

Comments

@nick87720z
Copy link
Contributor

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
Copy link
Member

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
Copy link

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
Copy link

pbrisbin commented Nov 3, 2021

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
Copy link
Member

fwsmit commented Nov 3, 2021

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
Copy link
Contributor Author

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
Copy link
Member

fwsmit commented Nov 8, 2021

I've thrown together a quick proof of concept in #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
Copy link

haselwarter commented May 12, 2023

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

@LamprosPitsillos
Copy link

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

@fwsmit
Copy link
Member

fwsmit commented Sep 6, 2023

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)

@bynect
Copy link
Member

bynect commented Jul 15, 2024

from now on you can hotreload with dunstctl reload #1350

@bynect bynect closed this as completed Jul 15, 2024
@bynect bynect modified the milestones: 1.7, v2.0 Jul 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants