Reload if config file changes about blocky HOT 5 CLOSED

For non docker setup it is cool, but what is if the config file is malformed after a change? Current implementation fails on start if config is wrong -> this is ok. But what is if working configuration has been changed and is not ok after config is saved and was automatically reloaded? Should last working configuration be used?

from blocky.

That is a valid point, in this case the feature should be optional.

For me this feature is not needed anymore because my helm chart will try a new deployment once the file changed if the new pod does not come up the old version would remain running... What would help would be some prometheus / health endpoint which could be used in order to know if everything is working fine.

from blocky.

My goal is to allow blocky to be disabled and re-enabled for specific devices and/or changing blocklists for specific devices without stopping the DNS blocking/forwarding of blocky.

Is it possible to push a new config file into blocky without any stopping of the DNS blocking/forwarding? Or, is there a better way to achieve the above goal?

from blocky.

Actual, the only way is to restart blocky. I use blocky as docker container, if I change config I just run "docker-compose down && docker-compose up -d", this takes only a few seconds. If you need 99.99% uptime of DNS resolver, I would recommend you to run 2 instances of blocky on different servers and use both as DNS1 and DNS2 in client config. In this case you can do maintenance on one server with blocky (change config, install updates etc) and your clients will automatically use the second instance.

from blocky.

Reloading of the config file on change is not a trivial operation: since almost everything can change, all components should be reinitialized, lists must be reloaded etc. In case of validation error, the old config (?) must be used, if other errors occur (e.g. port is in use), the application would not start.
To reduce such complexity, I recommend just to restart blocky. This would typically be very fast.

I'll close this issue, please reopen, if you're disagreed or have another suggestions

from blocky.