What's not working actually?
The discussed procd startup trigger affects only the boot behaviour. You can check the adblock service with this ubus call ...
ubus call service list '{"name":"adblock","verbose": true}'
# grep -A3 ' = "timed"' /usr/bin/adblock.sh
if [ "${adb_action}" = "start" ] && [ "${adb_trigger}" = "timed" ]
then
sleep ${adb_triggerdelay}
fi
So the documentation states that default delay for adb_trigger=timed is (default 30 sec.) , but it's actually adb_triggerdelay which is (int/default: '2').
[...]
if [ "${adb_action}" = "start" ] && [ "${adb_trigger}" = "timed" ]
then
sleep ${adb_triggerdelay}
fi
while [ ${cnt} -le 30 ]
do
[...]
regardless of the used trigger setting, adblock waits 30 seconds for the dns backend ... plus 2 seconds by default if you've started with "timed" trigger.
And, last resorts are sometimes where you have to go... Did the rm command, and got data coming back to me in the Runtime Information section... as well as the two buttons below it work. I can manually update the block lists now.
Is it normal that unbound uses almost twice as much memory as dnsmasq?
I have added some more list from http://hosts-file.net/
Adblock file has around 500k entries.
dnsmasq uses 80mb of memory, while unbound uses 160mb.
I tried changed the local-zone entries from static to always_nxdomain but that didn't reduce memory usage.
Is it possible to have the ad_list_* files removed from tmp after the dnsbackend has started up to free up some memory?
Can you also add an option to modify the --parallel paramter of sort ?
Also is it possible to have all other tasks, like awk, run in parallel like shown here: http://www.rankfocus.com/use-cpu-cores-linux-commands/
thank you.
Which files did you mean? After adblock processing you should see only one big file (adb_list.overall) in your dns related directory. Of course, this file can't be removed ...
There is no such option in busybox sort. "parallel" is an external gnu utility which is not available in OpenWrt. Please note, that all download related tasks (incl. sort) already running in parallel (check/raise the 'adb_maxqueue' parameter) - only the final list preparation runs sequentially.
Yes i mean the ad_list_* files.
Mine is around 20mb. Not that much. But keeping this in tmpfs is waste of ram...
Maybe an option to specify a path to keep the ad_list_* file on a permanent storage like an usb stick.
//edit
or maybe i should just move the entire unbound chroot to a permanent storage xS
I think i can be removed cause unbound (and dnsmasq) loads the entire file into ram at start up?
Maybe something like:
on adblock startup copy the adb_list_* files over to unbound chroot directory
after unbound has started, remove the adb_list_ files
only problem here is when unbound gets restarted at runtime the file has to copied again
Also when backup mode is enabled and the adb_list_* files were stored on a permanent storage, can't the adb list sources processing be skipped everytime cause list sources haven't changed?
Yes, i know but i use a custom build with coreutils-sort, which does by default use all cores anyway.
But i was thinking about limiting the parallel processing maybe to numcores-1 or something like that...
Thats awk doing the preparation? On a large list it really takes some time.
(~500k entries on 1,3 Ghz Arm)
//edit2
Can you make adblock use the $UB_VARDIR from /usr/lib/unbound/defaults.sh pls?
To bad it isn't possible to specify the unbound chroot directory in /etc/config/unbound.
So i have to mod the Defaults.sh everytime. I think i have to open issue on github xS
Thank you.
I have that enabled, it does skip the downloads, but adblock processes the entire lists again.
I mean, when the final adb file is stored on a permanent storage and backup mode is enabled, then the processing of the entire lists, actually can be skipped?
Hmm, latest openwrt master "snapshot" made dnsmasq ran out of memory, not sure what caused it, haven't changed the configuration.
Adblock version 3.6.5
There's 512mb memory in the router, I usallly have 250mb free with adblock up and running, so OOM seems weird.
Adblock is running well for me. I have a problem with DNS Query reports because although the router has been up for days, the "Start" time of the DNS Query report is usually only a few hours prior to the "End" time (i.e., current time). More specifically, given an uptime of a couple days shown on the Status Overview page:
Uptime 2d 0h 11m 0s
Then the first few lines of the report show the report start and end are only 4 hours apart:
Whenever I come back and run a report, I get pretty much the same thing. The "End" time is the current time and the "Start" time is a few hours before it. Adblock is enabled as shown through /etc/init.d/adblock status. I'm using a Linksys WRT1900ACS running the most recent davidc502 build which has adblock 3.6.5 installed.
I've poked around to see if there's an option I'm setting incorrectly, but haven't seen anything. The /tmp filesystem has plenty of room available and shows only 5% use. There is a tcpdump process running in support of adblock. Any advice?
Please be aware that any tcpdump change needs a full stop/start cycle of adblock, cause the tcpdump background task must be started with new parameters ... said that, you can check these with the following ps command (you change the "-C" and "-W" parameters).
Thanks! I did see the 'chunksize' in the readme, but the description didn't quite lead me to understanding that the parameters would control how much "effective time" of query that I'd get. In fact I'm still not quite sure. Basically I only get a certain number of chunks (defined by repchunkcnt) that are a certain size (repchunksize)? Which should I change? Or does it effectively not matter because the important parameter is actually repchunkcnt * repchunksize?
That depends on how chatty your LAN is ... by default the tcpdump background job is configured to use max. 5 chunks of 1 megabyte each to capture your network traffic in a "FIFO" loop. If you need long term statistics, change the report directory to a non volatile e.g. usb stick and raise the chunk size at least.
In fact I'm still not quite sure. Basically I only get a certain number of chunks (defined by repchunkcnt) that are a certain size (repchunksize)? Which should I change? Or does it effectively not matter because the important parameter is actually repchunkcnt * repchunksize?