That did it 
obsolete entry is gone.
And uninstall / install luci-app-simple-adblock brings it back.
Ah, it was a bad PR on my part, I'll send another one momentarily.
When this one gets merged, run: opkg update; opkg upgrade luci-app-simple-adblock;.
Until then, you can do:
rm -f /usr/lib/lua/luci/controller/simpleadblock.lua
rm -rf /var/luci-modulecache/; rm -f /var/luci-indexcache;
to get rid of the extra entry.
But, with the exception of the stale controller file, how are you liking the new Web UI for simple-adblock?
Much better than the old one.
I like the headlines, the tabs and especially the Status and the stop/start button 
Thanks for your efford on this.
Extra controller file fixed in trunk, not sure if it will be backported to 18.06 tho. If not before release I'll try to request backport shortly after.
1 Like
As an installable packages I think it is already part of 18.06, as there are only two package folders in downloads.openwrt.org/releases: packages-17.01 and packages-18.06.
Allready build in 18.06 for some like arm_mpcore but not mipsel_74kc yet (failed).
EDIT: mips_24kc build OK and I have succesfully upgraded luci-app-simple-adblock.
They were part of the 18.06 packages very early on, the question was wherever the fix would be back-ported from trunk to 18.06 and thankfully looks like it was.
Got it (now). Thanks again.
Running simple-adblock on a BT HomeHub 5A. Some downloads seem to be successfully downloaded by wget but then the sed and cat commands that immediately follow wget fail with a "No such file or directory" error.
I amended /etc/init.d/simple-adblock to show all the output from wget (below) and wget does seem to be successful.
I moved the download locations to a mounted USB stick (mnt/sda1) in case it was a space issue but that just triggered a "utime" error, again saying that there is no such file, some googling led me to adding --no-use-server-timestamps to the wget command which seemed to fix the utime error but not sed and cat failing.
Is there any further information I can provide to help diagnose this issue?
Cheers,
Ian
wget --no-use-server-timestamps --no-check-certificate --timeout 30 -v https://s3.amazonaws.com/lists.disconnect.me/simple_ad.txt -O /mnt/sda1/adblock/simple-adblock_tmp_7IIOzo63Q
--2018-07-28 22:46:54-- https://s3.amazonaws.com/lists.disconnect.me/simple_ad.txt
Resolving s3.amazonaws.com... 52.216.224.163
Connecting to s3.amazonaws.com|52.216.224.163|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 43642 (43K) []
Saving to: '/mnt/sda1/adblock/simple-adblock_tmp_7IIOzo63Q'
/mnt/sda1/adblock/simple-adblock_tm 100%[=================================================================>] 42.62K 2.01KB/s in 21s
2018-07-28 22:47:35 (2.01 KB/s) - '/mnt/sda1/adblock/simple-adblock_tmp_7IIOzo63Q' saved [43642/43642]
sed: /mnt/sda1/adblock/simple-adblock_tmp_7IIOzo63Q: No such file or directory
cat: can't open '/mnt/sda1/adblock/simple-adblock_tmp_7IIOzo63Q': No such file or directory
[DL] Blocked Domains: s3.amazonaws.com [✓]Ian, is this happening on 17.01.5?
No it's 17.01.2
I'm embarrassed that I didn't think to check for LEDE updates. I'll upgrade and see what happens.
Ian
The reason I asked is that it's been working flawlessly for me on 17.01.4 and both rc1 and rc2 of 18.06.0, however when I tested it on 17.01.5 I've experienced similar problems. I then heard that 17.01.6 will be coming out soon to fix some issues and I decided not to investigate further.
If the issue persists on 17.01.4 or any of the 18.06.0 builds, please post here/PM me.
I can confirm running into the identical issue when first evaluating simple-adblock and can't use it for that reason. The errors were under 17.01.4 and 17.01.5, on two different ar71xx routers.
The utime error actually shows that wget itself wasn't able to access the file after successfully downloading and writing it. I couldn't reproduce the problem by extracting and running the commands outside of simple-adblock. My first thought was some timing issue related to your code and/or an oddity of the tmpfs filesystem semantics but even that seems remote.
@guidosarducci, @bigwave -- I've updated the wget behavior a little bit in 1.3.6-7, I'd appreciate if you could test it.
The only time I've experienced this problem was on the "production" router which is running 18.06 right now and which I can't test on.
1 Like
The change on 1.3.6-7 fixed the issue for me. I'm using a TP-Link Archer C7 v2, had installed the package on 17.01.4 last night, upgraded to 17.01.5 and had no luck with either one. Thanks!
Like you, the problem occurred on my "production" router and I've already switched to using regular Adblock. I'll try to do some limited testing and suggest you do the same on your 18.06 router, since this is an awkward problem to debug.
Be aware that I already tried several changes, including your modification in 1.3.6-7, and none of them worked. The file appears to be missing when accessed after successful download.
BTW, I noticed the luci GUI reports success even in the event of many wget / sed errors, so the problem may be more widespread than reported.
Cheers...
I have it running in 18.06 no problem. The problem seems to be hard to replicate.
I'm only relying on the wget return code to get the status of download. I may rewrite this part of the code eventually, but I'd rather try to fix the problem.
Maybe a race condition within your background processing, e.g. missing wait step? I don't know the code ... just a rough guess ...
Yes, the background processing was one area I had concerns about before, and disabling it seemed to make things work... but not always. Certainly one aspect to investigate more or rework. I just tried again a few times disabling backgrounding and downloads worked.
BTW, another serious issue I remembered has to do with input validation. Some upstream list entries include non-encoded IDNA names which are not filtered out by simple-adblock. I saw these cause dnsmasq to crash and then fail, killing local DNS and allowing a nasty DOS courtesy of any malicious upstream source.
Just add (real examples)
local=/www.turkishạirlines.com/
local=/ɢoogle.com/
and watch the carnage as dnsmasq causes SEGV (17.01.x) or hits an error (18.06.x).
Please filter such entries with special characters (making sure of the correct locale!) so we worry less about untrusted input. Note that I haven't seen this issue with regular Adblock so guessing that @dibdot already does such filtering.
Cheers
When I first introduced parallel processing of files in the background (in early 2018 I think) I have also implemented a "run in background setting" but that just launched the main process in background with the goal of returning user to the shell prompt immediately. I have since (about a month or so ago) removed that setting from the code and the main process always runs in foreground.
Which OpenWrt/dnsmasq is that?
This is what I have in my simple-adblock file and dnsmasq sure does NOT choke on this:
# tail /var/dnsmasq.d/simple-adblock
local=/zzha.net/
local=/zzmyw.com/
local=/zzptzdhugavot.review/
local=/zzpxw.cn/
local=/zzshw.net/
local=/zztxdown.com/
local=/zzzezeroe.fr/
local=/zzzpooeaz-france.com/
local=/zzzrtrcm2.com/
local=/ɢoogle.com/
PS. There is filtering of the source files in simple-adblock.