Adblock-lean: set up adblock using dnsmasq blocklist

Yes, I agree, leave up to the user. Unless a wget file size before download option can be found (maybe not possible!)

Not possible with busybox wget I believe. Even then, there are other points in the code where the free space could be depleted. And as you point out, the trouble with:

no_blocklist_urls=$(echo ${blocklist_urls} | wc -w)
        max_required_space_KB=$((2*${no_blocklist_urls}*${max_blocklist_file_part_size_KB}))
        free_tmp_space_KB=$(df -P /tmp | tail -n 1 | awk '{print $4; }')
        log_msg "Number of specified blocklist URLs: ${no_blocklist_urls}; maximum specified blocklist file part size: ${max_blocklist_file_part_size_KB} KB"
        log_msg "Maximum determined required storage space: ${max_required_space_KB} KB; available free space in /tmp: ${free_tmp_space_KB} KB"

        if [[ ${max_required_space_KB} -lt ${free_tmp_space_KB} ]]
        then
                log_msg "There appears to be sufficient free memory to continue."
        else
                log_msg "Insufficient free memory. Exiting now."
                exit
        fi

is that it significantly overestimates the free space required.

1 Like

Looks like oisd.nl is down....hopefully only for a short time, lets see

I used adblock-lean before and everything worked fine. I reinstalled OpenWRT yesterday and ad blocking is not working anymore. Everything looks fine, but if I try the following command service adblock-lean start, the procedure starts, the blocklists are downloaded, but then the last few lines are the following:
Lookup of 'google.com' failed with new blocklist.
The dnsmasq check failed with new blocklist file.
No previous blocklist file found. Stopping adblock-lean.
Stopping adblock-lean.
Removing /tmp/dnsmasq.d/blocklist and restarting dnsmasq.
Stopped adblock-lean.
What am I missing?

One of the sanity checks that adblock-lean includes is to verify that lookups to certain big domains still work once dnsmasq has been restarted with the new blocklist. The thinking is that if any of those fail, the blocklist is likely bad. For some reason in your case, the lookup to google.com failed, and adblock-lean assumed the blocklist is bad, and hence looked for an old one to back to, found no old one, and so simply stopped with an error message. Are you using a custom blocklist or blocklist URLs?

I use default download links included in config file.

I also created an allowlist file and added google.com to it. During the procedure of starting the service, it was recognised and removed from the list of blocked domains. However, the same error still persist. So either I am doing something wrong or there is something wrong with the blacklist or service.

Could you please try without the allowlist? And if that works maybe send us your allowlist file to check over. Plus any local blocklist if you happen to be using that also.

Does running nslookup google.com 127.0.0.1 give a proper response without Adblock-lean?

I first tried without allowlist and it did not work. Then I created allowlist with only one entry (google.com). I received the same error as before, that google.com was not reachable.

Yes, google.com is reachable.

Update of the status: I removed big.oisd.nl blocklist and only left raw.githubusercontent.com/hagezi. The service starting procedure completed successfully, adblock-lean is now up an running. However, with limited size of the blocklist.

It is odd. I'm running big.oisd only, and without any issues. What router and how much ram does it have?

Nanopi R2S with 1GB, of which 870 MB is free. I am running the last OpenWRT snapshot build.

This is difficult to diagnose. Obviously not short on ram, and i don't think there are issues with the lean script either. Hmmm

Can you try adding 'sleep 10' after this line:

And run again with both list URLs?

I have no idea how to do this. Can you explain (step by step guide) what I should do?

Just edit /etc/init.d/adblock-lean to add that extra line.

I added sleep 10 after line 285 and it worked. Now both blocklists are uploaded. Thank you for all the support!

Excellent. So it seems that my hunch was correct that in certain circumstances dnsmasq just needs a little more time than what we are giving it at present to complete its restart with the new blocklist.


@Wizballs and @dave14305, I think this means that:

ubus -t 60 wait_for dnsmasq

can, in certain circumstances, trigger a little prematurely.

I wonder if we should revert to the old method:

for i in $(seq 1 60)
do
	nslookup localhost 127.0.0.1 &> /dev/null && break
	sleep 1;
done
1 Like

Good pickup, I guess what is possibly happening is that ubus is waiting for dnsmasq to be running, and not necessarily fully functional yet. Whereas nslookup is actually testing that dnsmasq is loaded and also fully functional.