Hello,
just a quick question: saving the “Network/Edit Hosts” page after an edit takes veeeeery loooong until my browser stops “waiting” → 5 Minutes regularly! Is that normal?
Yes this is “normal” behavior on my side, too.
Hm, OK. It’s really time-killing 
I don’t see that behaviour. I have 26 hosts listed on my hosts page and I just tried editing an entry and saving and then editing it back. Each time it was around 2 to 3 seconds.
I am using SeaMonkey which is a fork of Firefox running on Arch Linux. I also just tried it out on Firefox and it was a similar time of around 3 seconds.
After you have run an edit and it has taken so long do you see any messages in
/var/log/httpd/error_log
In the /var/log/httpd/access_log I just get the following one line when executing the hosts.cgi edit
192.168.26.32 - admin [27/Apr/2022:13:01:14 +0200] “POST /cgi-bin/hosts.cgi HTTP/1.1” 200 38170
and from the ````/var/log/httpd/ssl
I get the following single line
[27/Apr/2022:13:01:07 +0200] 192.168.26.32 TLSv1.3 TLS_AES_256_GCM_SHA384 “POST /cgi-bin/hosts.cgi HTTP/1.1” 38205
Do you see similar things or additional messages.
You could also look in the Logs - System Logs - IPFire in drop down box.
After editing the hosts file I get the following messages
13:01:14 ipfire: Hosts config changed
13:01:00 ipfire: Hosts config changed
12:56:26 ipfire: Hosts config changed
12:56:08 ipfire: Hosts config changed
Do you see any additional messages in that log related to the hosts file.
EDIT:
You could also check if the /var/ipfire/main/hosts file has the same contents as on your hosts.cgi page and that there aren’t any additional entries in the file that should not be there, although if there were then I would expect to see some message from it in the logs.
Hello and thanks for your answer and help.
I use Firefox, LibreWolf and also tried chromium with no difference.
Also I noticed: the five minutes seems to be a timeout. After that browser stops loading but page is not beeing updated → edited line is still “before save”.
access_log starts with:
10.38.82.2 - admin [27/Apr/2022:13:37:40 +0200] "POST /cgi-bin/hosts.cgi HTTP/1.1" 200 -
after that about 700 of this type:
10.38.82.2 - admin [27/Apr/2022:13:37:32 +0200] "GET /cgi-bin/speed.cgi HTTP/1.1" 200 140
ssl_request_log starts with:
[27/Apr/2022:13:37:31 +0200] 10.38.82.2 TLSv1.3 TLS_AES_256_GCM_SHA384 "POST /cgi-bin/hosts.cgi HTTP/1.1" 39005
and after that again lots of
[27/Apr/2022:13:36:31 +0200] 10.38.82.2 TLSv1.3 TLS_AES_256_GCM_SHA384 "GET /cgi-bin/speed.cgi HTTP/1.1" 140
In System Logs I can’t find any other messages regarding host change than:
13:37:40 ipfire: Hosts config changed
/var/ipfire/main/hosts seems ti look good except last line:
on,192.168.178.1,NAME,DOMAIN,
there’s an “on” missing at the end.
→ EDIT: I re-saved last entry via GUI and the last “on” then appears. Seems not to be the problem.
I noticed that the hosts file is updated immediately after clicking save in GUI. So I think the processes after that may be the problem (service restarts…).
What’s going on after saving the hosts file in the process of editing hosts? Maybe I could try it manually to see where the problem is.
Maybe interesting regarding my problem: I’m using this script to block lots of hosts: GitHub - sfeakes/ipfire-scripts: Scripts for ipfire
The speed.cgi lines are the cgi page that is run regularly to collect the traffic in and out data that you see at the right hand top of the main page.
So in both access_log and ssl_request_log you just have the single line as on my system.
Did you find anything in the /var/log/httpd/error_log file.
Normally there should be very little in there.
A couple of lines are all I have in mine
[Sun Apr 24 00:01:00.068563 2022] [mpm_event:notice] [pid 4997:tid 125177806268288] AH00489: Apache/2.4.52 (Unix) OpenSSL/1.1.1n configured – resuming normal operations
[Sun Apr 24 00:01:00.068690 2022] [core:notice] [pid 4997:tid 125177806268288] AH00094: Command line: ‘/usr/sbin/httpd’
If there are more lines than that then they might give some clue.
If that file is also just similar to mine then I am running out of ideas for why it should be doing that.
You only see this effect on the hosts.cgi file, correct?
In /var/log/httpd/error_log the mentioned timeouts are documented:
[Wed Apr 27 13:42:40.774363 2022] [core:error] [pid 26350:tid 140101547972160] (70007)The timeout specified has expired: [client 10.38.82.2:57986] AH00574: ap_content_length_filter: apr_bucket_read() failed, referer: https://ipfire:444/
I haven’t noticed any similar problems as with hosts.cgi.
That might have an effect. After the hosts file has been updated then the next, and last, step is to run the following two c programs
rebuildhosts and unboundctrl reload
As far as I can see the rebuild hosts is not checking the material from the hosts.cgi page.
However reloading unbound would get it to check all the hosts settings and maybe when it does that your host ip addresses are getting checked against the script you have in place.
I am not running that script.
Maybe you could do a test of disabling that script and then seeing if everything runs faster.
1 Like
Yes, I found that in hosts.cgi, too. And I found this thread regarding slow restart of unbound and this DNS blocking script: [issue] unbound restart / reboot need to long after update 139->141 - #2 by jayjay73
Unbound seems to be the “problem” in my configuration. I restarted it manually and noticed that this takes so long. My reboot are slow, too.
Maybe I could have a look at the bugtracker and write a change request regarding that.
Thanks for your help 
!
If you want to checkout what the two c programs are doing after the hosts file has been updated then the following two links are for the source in the IPFire git repository
Lines 486 to 492 in hosts.cgi is where the BuildConfiguration sub routine is that is run after each modification of a hosts entry.
hosts.cgi
1 Like
FYI, the unofficial ipblocklist addon that Tim FitzGeorge created in the past is being integrated into IPFire as a core program. I am not sure exactly which CU it will come out in but I would expect 168 or 169.
https://community.ipfire.org/t/can-i-help-progress-version2-of-ipblacklist-addon/6998
and after that thread a patch was submitted into the dev mailing list and has been worked on and is out for testing currently.
https://lists.ipfire.org/pipermail/development/2022-April/013123.html
3 Likes
That are great news I’ll have a look at it. Thank you so much!