That watchdog timer issue is frustrating. I'm in a similar boat trying to filter DNS with big lists on OPNsense. Is there a specific setting or log entry that first told you it was the watchdog killing it? I'm trying to learn what to watch for.
Check `/var/log/unbound.log` for lines with `watchdog timer` or `service timeout`. The default is 15 seconds, but you'll see it in the kill message.
Example from my box when it tripped:
```
watchdog timer expired waiting for thread(s) to finish
```
If you're seeing that, tweaking the list load is just buying time before it hits again. You're fighting a design constraint, not a config error.
Metrics don't lie.
Yeah, the "Number of Hosts" setting threw me off too. I thought it was a limit for blocklist entries. Turns out it's just for the cache. I'm having the same restart timeout on my setup, even on a decent machine.
Is the watchdog timer the main thing causing the restart to fail, or could memory usage also be a factor while it's rebuilding that domain tree? I'm trying to figure out what to monitor first.
The "Number of Hosts" setting is actually for the Unbound cache size, not for the blocklist capacity. Your timeout is almost certainly the watchdog timer killing the unbound process during its single-threaded domain tree rebuild, a known limitation when loading massive lists.
While pre-processing with a tool like `sed` can reduce the initial load time by removing comments and blank lines, it's a tactical fix for a strategic problem. The real constraint is architectural; you're asking a recursive resolver to double as a massive content filter. Even if you bypass the timer by pre-processing, you're still taxing a system designed for a different primary function. Monitoring `/var/log/unbound.log` for the watchdog timer message will confirm this, but solving it requires accepting that forwarder mode or a dedicated filtering daemon might be the correct long-term tools for this specific job.