Adblock-fast: ad-blocking service for dnsmasq, smartdns and unbound

I am also seeing this

root@DL-WRX36:/var/run/adblock-fast# /etc/init.d/adblock-fast dl
tail: can't open '/tmp/adblock-fast_tmp.XXnEDloL': No such file or directory
tail: no files
[DL] Config  Update:  cdn.jsdelivr.net [✗]
Starting adblock-fast 1.1.2-1...
[DL] Blocked File: cdn.jsdelivr.net [✗]
ERROR: failed to create /var/run/adblock-fast/dnsmasq.servers file!
adblock-fast 1.1.2-1 failed to start: Downloading...!
root@DL-WRX36:/var/run/adblock-fast#

On the luci UI, I see this:

I'd add the gstatic.com to the allowed domains and retest. Given the intermittent nature of the problem, maybe it has something to do with the upstream DNS? If not, are there any out of memory crashes in the system log?

Try clearing browser cache. Having said that, I don't know what modifications ImmortalWrt has over vanilla OpenWrt, neither am I able to test adblock-fast on ImmortalWrt.

If you can run the following commands in CLI and see if any of them take unreasonably long to respond, that would be the first investigation step:

ubus -v list luci.adblock-fast
ubus -S call luci.adblock-fast getFileUrlFilesizes '{"name": "adblock-fast" }'
ubus -S call luci.adblock-fast getInitList '{"name": "adblock-fast" }'
ubus -S call luci.adblock-fast getInitStatus '{"name": "adblock-fast" }'
ubus -S call luci.adblock-fast getPlatformSupport '{"name": "adblock-fast" }'

No, that should affect the functionality, but I was under impression that jsdelivr was not blocked in China, could you please clarify?

Weird, which OpenWrt version is that on? From CLI, can you post the output of:

ls -la /var/run/adblock-fast/
mkdir -p /var/run/adblock-fast/
touch /var/run/adblock-fast/dnsmasq.servers

Same questions as above, thanks!

Just yesterday's snapshot, r26581. Those commands didn't do much to troubleshoot.

root@OpenWrt:~# ls -la /var/run/adblock-fast/
drwxr-xr-x 2 root root 40 Jun 9 15:43 .
drwxr-xr-x 9 root root 520 Jun 9 21:42 ..
root@OpenWrt:~# mkdir -p /var/run/adblock-fast/
root@OpenWrt:~# touch /var/run/adblock-fast/dnsmasq.servers
root@OpenWrt:~# ls -la /var/run/adblock-fast/
drwxr-xr-x 2 root root 60 Jun 10 20:08 .
drwxr-xr-x 9 root root 520 Jun 9 21:42 ..
-rw-r--r-- 1 root root 0 Jun 10 20:08 dnsmasq.servers
root@OpenWrt:~#

Same errors are on LuCI page: Failed to start

My guess would be something has changed with the user the procd init scripts run from and/or default jail for procd scripts in the recent snapshot and the init script doesn't have access to the /tmp/ and /var/run/ anymore.

I don't have time to investigate this at least until the end of this week if not the next. If someone can figure out/let me know what's happening, I might be able to implement the fix quickly tho.

If you can run the following commands in CLI and see if any of them take unreasonably long to respond, that would be the first investigation step

I add this blocklist https://raw.githubusercontent.com/Cats-Team/AdRules/main/dns.txt and then getFileUrlFilesizes takes obviously longer to respond. Does that mean a user-add rule will be checked through Internet every time, and when the githubusercontent is inaccessible for me, it runs time out?

No, that should affect the functionality, but I was under impression that jsdelivr was not blocked in China, could you please clarify?

In fact, github/openwrt/jsdelivr are not literally blocked but unregistered in China. I think some of their servers are blocked while most of which are still reachable. They are usually accessible, and if not, we can just wait one or two minutes to have a retry and the DNS may respond an other unblocked server. Google/Facebook/twitter are definitely blocked, so that they are total unreachable unless via vpn.

Thank you for bringing it up and elaborating on the issue.

There's a code which tries to determine the file size of all added block-lists by downloading first 512 bytes or so if I remember correctly. The sizes are then displayed in the WebUI so that users can decide which block-lists they can enable without running out of memory on the router.

Obviously, the assumption was that you're only adding the block-lists to the config which are accessible to you, I'll try to play with that code to see what can I improve so it fails faster for the links which are inaccessible.

Thanks for reply and the following works.
I suggest that you might modify the process flow to let the web UI load first and then determine and refresh the file size of every blocklist.

There's a code which tries to determine the file size of all added block-lists by downloading first 512 bytes or so if I remember correctly.

Does this all added block-lists mean all and only the blocklists added by user himself or both package-provided and user-added blocklists? When I say the Cats-Team Rule will make the getFileUrlFilesizes taking obviously longer to respond, I mean even the one and only rule had been added and size determined, getFileUrlFilesizes will still take longer to respond every time when it's called. So it seems that user-added rules are always being unfairly treated from the package-provided ones, which is quite logically wired. I don't think it's a result of inaccessible problem, because there are other package-provided github raw rules such as the AdguardTeam ones.

No, if the size is known, it's not being refreshed on getFileUrlFilesizes. Realistically, unless you're adding unavailable to you lists, it all works very fast. You're welcome to contribute any code you may consider improvement to the original source repo.

No, if the size is known, it's not being refreshed on getFileUrlFilesizes .

I find that /etc/config/adblock-fast will not update the file size that the web UI has known. Does this only happen to me?

I edit the config file and give it a random option size, then everything runs well now.

1 Like

Thanks for spotting and reporting this! Version 1.1.2-2 (in my repository) contains the fix for the file size not being stored in config. You'll need to update both principal package and the luci app.

1 Like

I've had another theory, maybe just the /tmp had gotten smaller (due to a bigger kernel or something). @odhiambo @phinn can you try with only the smallest list and see if that works?

Unchecked everything, restarted the service, picked the smallest block list on the list 10.89 KB at the bottom. Same results it won't start:

Status
Version 1.1.2-1 - Failed to start.

Service Errors
Failed to download https://cdn.jsdelivr.net/gh/hoshsadiq/adblock-nocoin-list/hosts.txt!
Failed to create '/var/run/adblock-fast/dnsmasq.servers' file!
Failed to create block-list or restart DNS resolver!
Errors encountered, please check the README!