Self sign-up has been disabled due to increased spam activity. If you want to get access, please send an email to a project owner (preferred) or at gitlab(at)nic(dot)cz. We apologize for the inconvenience.
This is probably nothing about Knot DNS, but configuration of systemd. Please consult systemd manual.
Just guessing: probably systemd has a timeout for service startup, in order to detect faulty service taking too long (possibly infinity) to get up and running. You might need to adjust this timeout, maybe in /etc/.../knot.service.
I found that the reason for the starting service timeout is that the execution of the /usr/sbin/knotc conf-check is too slow, so I manually executed this command and then used systemctl start knot to start the service
TimeoutStartSec= from systemd.service(5) seems relevant, although I haven't tried if it works with ExecStartPre option that executes the conf check. If it does, overriding this timeout might be an option.
I'm not sure how much this value is set. I suggest that if the server is just started, first execute /usr/sbin/knotc conf-check, and then start knot, after executing /usr/sbin/knotc conf-check , The system has a cache for it, start knot again, it will not fail to start.
Get similar issue, When I execute systemctl reload knot:
TimeoutStartUSec=0TimeoutStopUSec=0
I think this problem is very serious because our DNS file needs to be reloaded every 5 minutes, I also enable async-start, and I found that there will be a delay when executing systemctl reload knot.
I suspect you reached the limit of maximum configuration database size. How do you install Knot DNS (from a package or from sources)?
Please note that server reload cannot be immediate as possible ongoing zone events have to be finished first!
Maybe you should use configuration database instead of configuration file as it's optimised for huge deployments and is capable to track simple configuration changes.
The benefit of using configuration database instead of configuration files would be that you would stop using configuration files whatsoever, and instead of modifying them, you would directly modify the configuration database via knotc interface ;)
OK, then the repeated conf-import will work as you desribed, but there is not much of a benefit.
Some alterative could be not to use configuration database, and stick with configuration files like at the beginning. You just can avoid re-starting knotd by systemd (like systemctl reload knot), you just can tell knot to re-load the configuration file by knotc reload.