No, you’re not. Which phone? Do you have Application only set in Chum? Version there?
Ok, now I am relieved.
Yes. application only. Found it now, thank you!
One question i updated to last version. Now the script runs every day or again when i perform a reboot. I mean the previous version the script runs only 1 per week ?
From /usr/share/doc/hosts-block/cfg.sh:
## Online update interval in days, integer only
## Regardless, systemd will run the service once day
## to check if this timeout is reached
##
interval=7
Additional updates are run as soon as you edit or create anything in ~/.config/hosts-block.
Not even a reboot should™ change anything about that logic.
If you want to troubleshoot this further, you can trigger the service with
devel-su
hosts-block; journalctl -f | grep hosts
And post the output or, even better, enable persistent logging and post
devel-su
systemctl status hosts-block.timer hosts-block.service hosts-block-forced.service hosts-block-watch-config.service
journalctl -b | grep hosts
I can now confirm that the watch-config.sh script triggers a full online update after a reboot. That’s (usually) unnecessary, but the watch logic is not easy to get right. I wanted to include all edge cases.
Nevertheless, this is unwanted behavior and should be fixed. I’m on it.
The hosts-block service is triggered often, but usually it does not download anything - that definitely happens only at $interval days - and re-uses cached data. The impact on resources is minimal in these cases.
I have now changed watch-config.sh so that it does not needlessly trigger an upate on each reboot.
And made sure that no other needless updates are triggered beyond what $interval states (i.e. 7 days by default).
However, a specific edge case is now left unconsidered: renaming (moving) ~/.config/hosts-block does not register as a config change anymore even if it contains valid files.
Not removing/deleting though!
Since this would only affect power users I think it’s OK and possibly better than having superfluous updates.
If this concerns you, systemctl start hosts-block-forced will trigger a full update.
This is in chum:testing now and if nobody objects I’ll push to chum soon.
It’s been accepted so this is in Chum’s main repository now. ![]()
Let me just quickly address the lack of a GUI: simply installing this app should™ immediately enable a sort of medium strict adblocking. There’s a clickable restart notification for the browser, but other apps might need to be restarted in other ways.
Once it’s rolling, the lists don’t change too often (esp. the most crucial entries) so you can lean back and just enjoy.
That said, a QML GUI is on the TODO list and help is welcome. Mostly for editing all 3 files in ~/.config/hosts-block, at least for starters.
Of course, real hackers use butterflies.
@ohnonot Just a massive thank you for this app! The default sailfish browser is much faster now and it causes no problems. Using hosts-block for several weeks now and will probably do it all the future. ![]()
Heads up, hosts-block of course still works on 5.1., including appsupport.
Are you sure you mean 5.1 and not 5.2?
Yes. 5.1.0.11 Pispala to be precise.
Though I don’t see why it wouldn’t work on 5.2. I just don’t have access to it.
I have it running on 5.2 and it works just as great as before