I'm using stubby on two routers running snapshots. On both I have issues with starting the stubby properly.
If I enable the service its getting started during the boot. But it seems to fails due to runtime issues. My guess was either WAN is still not up respectivley it is not detected correctly if its up and/or time synchroization is not setup in time.
The log is full with this after boot:
daemon.err stubby[5311]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
But this is missleading.
My approach was to disable and start it manually via rc.local. This works only if I enable the service (and let it fail on start) and restart the service via rc.local. Playing around with start delay for stubby in rc.local it didn't solve the problem reliable. Even with insane delay times. It did work sometimes, sometimes not.
During my search I found this:
But chaning user to "nobody" just blocked the start. My Interface is WAN so no need to change it like for mwan (like proposed within this thread).
The only thing that worked (beside my rc.local approach) was to completely remove the user setting in the init.d-file to run stubby as root.
procd_set_param user stubby
But that should not be the solution. Beside that the former maintainer was not able to reproduce on x86_64 it and gave advise to use the upgraded version.
But we are now at v0.4.0-6 and not 0.2.4 anymore.
So my question is what to do? Is there anyone with the same problem? Is there a new maintainer?
If you notice that the date/time is wrong for those entries, then in /etc/config/dhcp add the following after list server '127.0.0.1#5453' (or whatever your stubby port is):
list server '/pool.ntp.org/8.8.8.8'
This will make it so any time synch requests are sent through Google DNS plain 53 and not Stubby, which will allow OpenWRT to properly sync date/time which will in turn make Stubby work.
I've ensured time is correct with any measure and setup a 2nd timeserver for my network to be sure. Time is picked up correctly but probably to late for stubby (max. tries exceeded already probably before it stops).
IMO this is a design bug. If stubby cannot connect (for whatever reason) in first place it get stucked on trying until its limit is reached and then crash/stop for any reason. This is the 1st part. I think this is either WAN (no clue what is checked here exactly) or time related (stubby=S30; sysntpd=S98).
2nd part is the fact that a restart (either manual or via rc.local) fails sometimes and sometimes not (mostly it fails). For this reason I have removed the line "procd_set_param user stubby" in /etc/init.d/stubby.
ATM I have:
sleep 20
/etc/init.d/stubby restart
in rc.local
and removed the line:
procd_set_param user stubby
within /etc/init.d/stubby
I don't want to dig into this further. It seems to me that there are not so many stubby users out there running snapshot builds (I didn't crosscheck stable). So I'll stick to my workaround.
P.S. I have to mention that I have declared to ignore WAN DNS (but even with it's not reliable starting) and I have delcared only one TLS DNS server within stubby.
But that should not hinder stubby to run properly. E. g. check if WAN is online, DNS server is available and time is set correct periodically at least. I didn't found an option for max. retries before stubby is stopping itself. Tough I tried "option triggerdelay 5" instead of 2. Nothing changed.