Where is your basedir located? That's used during adblock processing, e.g.
Base dir is not set so it's defaulted to "/tmp"
This is the same setup across all my routers with adblock.
1 Like
Please retest with latest update:
1 Like
Ok will do..
But for now here is the log from the regular reload.. looks like one of the files failed
Tue Feb 24 05:08:10 2026 user.debug adblock-4.5.1-r3[23768]: f_list ::: name: hagezi, mode: backup, cnt: 531502, in_rc: 0, out_rc: 0
Tue Feb 24 05:08:11 2026 user.debug adblock-4.5.1-r3[23768]: f_list ::: name: hagezi, mode: prepare, cnt: 531502, in_rc: 0, out_rc: 0
Tue Feb 24 05:08:11 2026 daemon.err adblock.sh[23768]: BusyBox v1.37.0 (2026-01-21 21:31:18 UTC) multi-call binary.
Tue Feb 24 05:08:11 2026 daemon.err adblock.sh[23768]:
Tue Feb 24 05:08:11 2026 daemon.err adblock.sh[23768]: Usage: rm [-irf] FILE...
Tue Feb 24 05:08:11 2026 daemon.err adblock.sh[23768]:
Tue Feb 24 05:08:11 2026 daemon.err adblock.sh[23768]: Remove (unlink) FILEs
Tue Feb 24 05:08:11 2026 daemon.err adblock.sh[23768]:
Tue Feb 24 05:08:11 2026 daemon.err adblock.sh[23768]: -i Always prompt before removing
Tue Feb 24 05:08:11 2026 daemon.err adblock.sh[23768]: -f Never prompt
Tue Feb 24 05:08:11 2026 daemon.err adblock.sh[23768]: -R,-r Recurse
Tue Feb 24 05:08:30 2026 daemon.err adblock.sh[23768]: sort: write failed: 'standard output': No space left on device
Tue Feb 24 05:08:30 2026 daemon.err adblock.sh[23768]: sort: write error
Tue Feb 24 05:08:30 2026 daemon.err adblock.sh[23768]:
Tue Feb 24 05:08:30 2026 daemon.err adblock.sh[23768]: gzip: stdout: Broken pipe
Tue Feb 24 05:08:31 2026 user.debug adblock-4.5.1-r3[23768]: f_list ::: name: -, mode: merge, cnt: 322299, in_rc: 4, out_rc: 2
Tue Feb 24 05:08:33 2026 daemon.info dnsmasq[13506]: exiting on receipt of SIGTERM
Tue Feb 24 05:08:39 2026 daemon.info dnsmasq[24917]: started, version 2.91 cachesize 10000
Tue Feb 24 05:08:39 2026 daemon.info dnsmasq[24917]: DNS service limited to local subnets
Tue Feb 24 05:08:39 2026 daemon.info dnsmasq[24917]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth DNSSEC no-ID loop-detect inotify dumpfile
Tue Feb 24 05:08:39 2026 daemon.info dnsmasq[24917]: UBus support enabled: connected to system bus
Tue Feb 24 05:08:39 2026 daemon.info dnsmasq-dhcp[24917]: DHCP, IP range 192.168.20.150 -- 192.168.20.249, lease time 1h
Tue Feb 24 05:08:39 2026 daemon.info dnsmasq-dhcp[24917]: DHCP, IP range 192.168.10.100 -- 192.168.10.254, lease time 12h
Edit: I haven't updated the adblock.sh yet but something is really weird happening via cron for that very specific schedule hahahaha.. i've got a second reload setup and it reloaded properly.
I'll update adblock.sh (or the whole adblock) tomorrow after the next regular run. I just want to see what happens. Below is an updated cron for adblock. The original schedule is the one sandwiched in between (5:05am). I just want to see what happens for the before, original and after.
45 4 * * * /etc/init.d/adblock reload
5 5 * * * /etc/init.d/adblock reload
45 5 * * * /etc/init.d/adblock reload
Note: I don't have any conflict schedules for those times or even other schedules near them.
That looks weird, obviously. How much space is “free” in /tmp?
Currently it's at 145MB free. It might be a storage issue on the /tmp but the weird part is, on the second cron it worked hahaha. Need to check tomorrow, since it's only happening on that specific schedule.
OK, thanks - than it's clear. By default adblock uses these sort options:
adb_srtopts="--temporary-directory=${adb_tmpdir} --compress-program=gzip --parallel=${adb_cores}"
To mitigate your problem point your adblock basedir to a mountpoint with more space. You can also try to reduce/set the number of used cpu cores (option adb_cores in config), but I'm unsure if that really helps.
1 Like
Can confirm it's a storage/memory issue. It seems by the time the first reload hits, there is not enough space left in /tmp to process all of the selected blocklists.
I did point the base dir to the external storage at the start but changed to default last year on all my routers. So I guess I need to point it back to the external drive hahaha
Thanks @dibdot and also to @dave14305
2 Likes
A new DNS‑Bridge feature has landed in adblock 4.5.2‑1 in master & 25.12-branch.
Beside enhanced debug capabilities, it introduces a lightweight firewall‑based fallback path that keeps DNS resolution fully available while the local resolver restarts. This means Zero‑Downtime DNS during rule updates, backend reloads, or configuration changes. The bridge activates only for the restart window and is removed automatically once the resolver is back online, ensuring seamless operation without altering your normal DNS flow.
As usual, the setup is quite easy, just a click away (on the Firewall Settings tab) ...
Have fun!
Dirk
Edit:
Logfile excerpt:
[03/01/2026-09:46:15] adblock-4.5.2-r1[12565]: adblock instance started ::: action: restart, priority: 0, pid: 12565
[03/01/2026-09:46:15] adblock-4.5.2-r1[12565]: adblock-related nft remote allow rules prepared for external DNS 86.54.11.100 / 2a13:1001::86:54:11:100 with timeout of 15 minutes
[03/01/2026-09:46:15] adblock-4.5.2-r1[12565]: adblock-related nft block rules prepared for external DNS 86.54.11.13 / 2a13:1001::86:54:11:13
[03/01/2026-09:46:15] adblock-4.5.2-r1[12565]: adblock-related nft local DNS enforcement rules prepared for devices: br-lan.10, br-lan.20, br-lan.30 and ports: 53, 853
[03/01/2026-09:46:15] adblock-4.5.2-r1[12565]: adblock-related nft rules loaded
[03/01/2026-09:46:25] adblock-4.5.2-r1[12565]: external DNS bridge loaded: 86.54.11.13 / 2a13:1001::86:54:11:13
[03/01/2026-09:46:38] adblock-4.5.2-r1[12565]: external DNS bridge removed
[03/01/2026-09:46:39] adblock-4.5.2-r1[13798]: mail successfully sent to 'xxx'
[03/01/2026-09:46:39] adblock-4.5.2-r1[12565]: blocklist with overall 753 781 blocked domains loaded successfully (Bananapi BPI-R3, mediatek/filogic, OpenWrt SNAPSHOT (r33241-525a1e94b3))
To test DNS outages from a connected linux client, just start something like that:
watch -n 0,5 'dig www.spiegel.de'
Every half second the dig command will be fired up ... 
9 Likes
I think there's a problem with the new adb_errorlog pointing to /dev/null and wiping out /dev/null's special attributes.
Restarting adblock causes the file to become "normal". If I enable adb_debug which changes adb_errorlog to something besides /dev/null, it doesn't clobber the file. This is before and after a restart:
root@router:~# ls -l /dev/null; service adblock restart; sleep 5; ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Mar 4 21:27 /dev/null
-rw-r--r-- 1 root root 136 Mar 4 21:34 /dev/null
This was setting debug and everything was fine:
root@router:~# uci set adblock.global.adb_debug='1'
root@router:~# uci commit adblock
root@router:~# ls -l /dev/null; service adblock restart; sleep 5; ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Mar 4 21:27 /dev/null
crw-rw-rw- 1 root root 1, 3 Mar 4 21:27 /dev/null
This has unintended consequences of being unable to perform a sysupgrade. See my post at OpenWrt 25.12.0-rc5 - Release Candidate - #196 by dave14305
EDIT: I imagine this line removing adb_errorlog could be to blame when set to /dev/null?
7 Likes
Oh, nice find! I was imagining something like this happening, but had no idea where to start digging. All three of my devices showing the broken /dev/null have latest adblock installed.
1 Like
Fortunately, I only have adblock and sqm-scripts installed, outside of core services. I had a 50/50 chance to find it on the first try. 
Also, I've edited my local adblock.sh to change that particular line to:
root@router:~# diff -u /rom/usr/bin/adblock.sh /usr/bin/adblock.sh
--- /rom/usr/bin/adblock.sh 2026-03-02 19:14:15.000000000 -0500
+++ /usr/bin/adblock.sh 2026-03-04 22:55:46.336639609 -0500
@@ -110,7 +110,7 @@
adb_errorlog="${adb_basedir}/adb_error.log"
: > "${adb_errorlog}"
else
- rm -f "${adb_errorlog}"
+ rm -f "${adb_basedir}/adb_error.log"
fi
# fetch installed packages amd system information
Cleanup the debug file only, until we hear from @dibdot.
5 Likes
Very good find!
Ouch 
Hi @dave14305 ,
thanks for the finding - I'll take a look later this evening.
2 Likes
What do you mean exactly?
While:
adb_errorlog="/dev/null"
Could cause trouble?
Yep, of cause - the rm is faulty (just replace the line with adb_errorlog="/dev/null") ... but you showed line 63.
only causes trouble because of line 63, I think
But it can be easily fixed 
P.S. Long time user of your very good Adblock package
@dave14305 @efahl @egc
the error logging issue has been fixed in adblock 4.5.2-2:
Sorry for the mess.
12 Likes