Good evening,
it also happened to me that after the update to 158, the proxy service does not restart automatically at every restart.
I noticed that it is flagged “Suppress version information:” and there is no way to remove it, it wasn’t there before.
I noticed that to restart the web proxy, I just need to click on a button also to clear the cache.
I have another firewall with the same version of ip-fire, same hardware but if I restart it the service starts regularly
My hardware is:
Intel J1900 with 4GB Ram and 32 GB ssd and 4 lan
IPFire 2.25 (x86_64) - Core Update 158
Second, thanks to everyone who is contributing here. Running Squid on a bunch of x86_64 IPFire machines (some of them log queries, but most don’t), I did not observe this behaviour so far, hence I am still trying to figure out what is going on here.
My understanding so far is: We are dealing with Squid not staring properly on x86_64 systems only (but not all of them), doing so since Core Update 154 at least. Re-writing its configuration (i. e. toggling log settings or something similar) solves the issue in all cases.
This seems to be a different issue then, as every other user described Squid to be unresponsive to any query. Or did I misunderstood you?
This was my fault again. Introduced here, I thought it might be a good idea to enable this switch by default, as there is no legitimate reason why Squids version matters. That patch seems to be faulty though, ignoring user requests to actually show the version information.
I’m still investigating. Sometimes clearing the cache isn’t enough. Sometimes “save and restart” will work. Other times I do nothing and it seems to be working next time I check the news.
It could also be related to the occasional issue I have with “connectivity check” on ubuntu and the phones.
I believe what I’m seeing is different to the other. Sorry.
Good morning,
as for the squid service not starting, I thought about creating a bash script.
I have scheduled the script to start every minute.
If I find the squit service “running” I do nothing, otherwise I start it.
Am I doing the right thing or do I risk doing more harm than good?
This is the bash script, I put it into a /home/nobody/test_squit.sh
#!/bin/bash
# Check if squid is running
# -x flag only match processes whose name (or command line if -f is
# specified) exactly match the pattern.
if pgrep -x "squid" > /dev/null
then
echo "Running"
else
echo "Stopped"
/etc/rc.d/init.d/squid start
fi
# IPFire - monit control file - squid
check process squid with pidfile /var/run/squid.pid
not every "25-40 1 * * *"
start program = "/etc/init.d/squid start"
stop program = "/etc/init.d/squid stop"
if not exist then alert
if not exist for 1 cycles then restart
if 5 restarts within 5 cycles then timeout
‘squid’ will NOT be checked during (daily) ‘squidguard’ updates.
You’ll get an alert if pidfile doesn’t exist during a cycle (e.g. 60 seconds). This can be tuned to your needs with, e.g.:
if failed host localhost port 3128
And - if process doesn’t exist or doesn’t answer - it’ll be automatically restarted.
Besides, I never had such problems with non-transparent ‘squids’ - really weird…
Hello,
I’m not an expert in the linux world, I tried to see if I could find a work around that would allow me to patch up this bug.
You say not to check the squid service between 1.25 and 1.40 because the updates are in progress right? but why?
You could modify the crontab so that the verification is done only once, when the firewall is started, since it is at that moment that the service does not start, in fact I have noticed that once it has started I do not find anomalies.
Honestly I should be looking at how to get it checked only at boot.
As I wrote: because at that time ‘squidguard’ loads its daily updates and ‘squid’ restarts too. In that case, ‘monit’ sometimes complained that ‘squid’ wasn’t running. But that was normal and I wanted to avoid false positives.
Of course you can modify crontab - I use ‘monit’ because I still monitor other processes in this way.
Try to change some settings in the “Network → Web Proxy”:
Memory cache size (MB): 10
Harddisk cache size (MB): 1024
then press the “save and restart” button.
Based on your reports and the log messages, I am getting the feeling this bug is related to the proxy cache. Below is a screenshot of the proxy configuration of an IPFire machine which has been running stable for years in this respect.
My cache management has been disabled all time.
I scheduled a reboot every morning and proxy service not starting correctly.
I can see this using Niva’s script.
05:00:00
ipfire:
ConnSched reboot
05:00:12
ipfire:
NTP synchronisation
05:02:17
ipfire:
NTP synchronisation
06:01:00
ipfire:
CheckSquid: Starting Squid Proxy Server…
07:01:00
ipfire:
CheckSquid: Squid Proxy Server is already running…
I am not quite sure about it, but it seems to occur only in conjunction with either SquidClamAV or the update accelerator enabled. Without these two, Squid runs stable. The URL filter also does not seem to cause the problem.
Could you try disabling SquidClamAV for a while, and report if this changes anything?
Sorry for not having a more precise idea on how to tackle this issue.
thank you for reporting back, and sorry for my belated answer.
This is unfortunate indeed: On some IPFire installations, Squid seem to behave odd no matter which additional components are enabled or disabled. I continue to be out of ideas what happens here - sorry.
Will do some testing and experimenting over the course of the next few days, in the hope of somehow reproducing that problem…
Sorry to disappoint, and best regards,
Peter Müller
I know that this is an old thread but wanted to see if any progress has been made with this issue as it starting happening to my IPFIRE installation begining with 169. I was able to take a backup of my configuration and load it to a virtualbox vm of 172 and have the same issue there so if you are interested, I can share that vm image with you so you can investigate.
