openwrt / luci

LuCI - OpenWrt Configuration Interface
Apache License 2.0
6.28k stars 2.51k forks source link

adblock plugin - problem global saving changes #708

Closed build000 closed 8 years ago

build000 commented 8 years ago

Any update (eq. when restart router or...when enable cron service to update definision/adresses) not automaticaly saving changes = you have to manually enter changes each time.

hnyman commented 8 years ago

I am not quite sure what you do mean. the luci-app-adblock plugin just uses normal uci to store settings like any other change made via luci.

@dibdot

build000 commented 8 years ago

So I have added more information about this error in "packages". In addition, there is already an error: When you restart the computer /etc/init.d/adblock in the terminal (or the luci) disappears this service from https: //openwrt.lan/cgi-bin/luci/admin/system/startup and `root@OpenWrt:~# /etc/init.d/adblock restart

<13>May 1 19:43:50 adblock[20650] error: adblock service already running (2519 root@OpenWrt:~# /etc/init.d/adblock stop <13>May 1 19:45:51 adblock[20655] error: adblock service already running (2519 root@OpenWrt:~# /etc/init.d/adblock start <13>May 1 19:45:58 adblock[20658] error: adblock service already running (2519 ` and ... As soon paste image http://i.imgur.com/PFtcNs1.png Filtering fragments log when router/system next startup (in config enable all position to uses luci): http://wklej.org/id/2370564/ My timezone is Europe/Warsaw...
dibdot commented 8 years ago

I can't see any problem. You've enabled all block list at once and adblock only commits all changes at the end of the processing to config (to minimize flash updates). So please wait until adblock processing has been finished - same applies to start/stop/restart cycles.

build000 commented 8 years ago

Also just I thought - so much that it took 25 minutes and no change - luci still requires manual saving changes ... In addition, the earlier version adblock / luci-app-adblock was not the problem with the need to manually saving changes to the luci (in general nothing showed on the interface at the moment when the service was started adblock) - so I guess, but this is a mistake.

dibdot commented 8 years ago

in your screenshot I'll see a processing time of about 2 minutes for all lists ... did you see a final log entry like ... adblock[8353] info : domain adblock processing finished successfully (1.1.0, r49276, 01.05.2016 20:52:31) ? If not, please disable a big list like shalla and try it again ... maybe a resource limit on your router.

build000 commented 8 years ago

I'll be back for a moment to what I wrote early in this and another post:

Seemingly while the error no matter what ideology we adopt in determining the issue of "readability interface luci", is that it simply disappears position service adblock list on the page / tab management available in the luci services (/cgi-bin/luci/admin/system/startup) and at a time when for once we use on this side of the "click" start/stop/restart/disable/enable.

... maybe a resource limit on your router.

firmware is 15 MB for 16 MB NOR flash (WiTi board) and 256 MB RAM, 2 core/4 threads processor 880 MHz (mt7621AT) Once again I emphasize - in previous versions it was not a problem.

dibdot commented 8 years ago

Please answer my question! adblock 1.1 adds 3 new block list sources ... and do the config update/commit only at the end of processing. Use default setup (in /etc/adblock/adblock.config.default with 3 enabled lists) and start from there ... still it doesn't make sense to always restart an already running service.

build000 commented 8 years ago

So the fundamental question - why so plugin luci (or /etc/config/adblock) as many possible letter to the inclusion, since their inclusion causes a problem with the operation of both the script and the luci ???

... still it doesn't make sense to always restart an already running service.

The explanation is simple - I have just more than one WAN interface and several LANs and each case is charging different number of addresses - perhaps it is also a deeper problem with the DHCP and the current route packets (maybe ISP also have some filters the pages of addresses = different ISP, different filters) - therefore I have a cron set to restart the service from time to time, when my main WAN is currently a network ...

build000 commented 8 years ago

Important observation: in the last version adblock with a large number of addresses (more loaded lists than the default) never appears in the log line "finished" - here's the problem - because luci always shows the need to manually save your changes, in spite of that (I presume ) addresses are loaded into the firewall ...

dibdot commented 8 years ago

Did you re-test with the latest version (1.1.1)? Did it work with the default setup? If so, please drop me a mail to my maintainer email address (see readme) and I'll send you a debug version.

build000 commented 8 years ago

1) Yes - if use "default" settings (not any config), its ok (even after rebooting the router and configuring any other services), like this: `Fri May 6 00:46:53 2016 user.notice adblock[1999] info : adblock lists with overall 6090 domains loaded

Fri May 6 00:46:53 2016 user.notice adblock[1999] info : domain adblock processing finished successfully (1.1.1, r49296, 06.05.2016 00:46:53)`

loading list (view to LuCI):

  1. adaway (408 addr.)
  2. disconnect (3276 addr.)
  3. yoyo (2406 addr.)

2) If I change anything through plugin luci (I'll add other lists or return later to set the default), the last message adblock at startup is:

Fri May 6 2016 1:20:56 user.notice adblock [2024] info: adblock lists with overall 6090 domains loaded

As you can see never again no line appears in the logs that discusses the "finished" (and then disappears service adblock from the cgi-bin/luci/admin/system/startup - about which I wrote a few times). Also, the number of loaded pages does not matter, only the script itself can not as before to cause the automatic behavior changes for later use luci when the service is installed adblock and its plugin for luci - that's the problem, and I'm surprised that I just I noticed.

What my configuration may differ from the basic is that I have more than one type of WAN interfaces (eg. Mobile modem and cable modem - two different ISP), managed properly at the start, depending on the time of day.

3) And one more important thing - you can not see the process adblock after the command "ps -w" (or htop - it depends on who uses what, and it is convenient for him) - there is no prces of the PID resulting from logs (that it looks as if the all this service is not started, if the pouring is not currently in logs for the service type "finished" - as if an adblock sub-process is not finished, which does not go to the main process of a different pid). So you can not kill the process and start again ...

dibdot commented 8 years ago

It's probably unrelated to luci and unrelated to your multiwan setup, I think it's a memory (hardware) issue on your router. The adblock process dies silently after memory intense sort processing and after that your system seems to be "borked" - until the next reboot. As I wrote before, to nail this down write to my maintainers email address ...

build000 commented 8 years ago

And it seems to me that this was recently made changes in the script make this probelm - with version 1.0.1 (3 "commits" ago) I set up a cron restart services every two hours, and the process always ended properly line "finished" in the logs ...

EDIT: While problem walked amateur (but effective - solution to help my version two WAN interfaces/and more - this is no any multiwan/multiwan3)- script taking off the WAN depending on the time of day (both at startup and in cron) added an extra option:

rm -f /var/run/adblock.pid && /etc/init.d/adblock start

Now (once you start the WAN) just destroy information about the running adblock and run it will repeat - now the start is always full and complete line of "finished" in the logs - also disappeared problems with luci ...

EDIT II:

Until ashamed to admit, but I ran straight to the simplest possible way to solve my problem (considering my unusual support for multiple WAN interfaces) ... manner so trivial as to be "painful":

"sleep 15" in /etc/init.d/adblock - the problem disappeared as hand subtract .. :+1:

Therefore, I close this topic.