Since upgraded to 170 I have had an issue with squid not starting on a system start.
Today I put a symlink from /etc/init.d/squid to /etc/rc.d/rc3.d for squid and now on a restart squid will start.
Initially I tried to fix this by disabling the webproxy and then re-enabling it but that did not solve the issue.
My question is, should there be a symlink for squid and if so, what is the proper name - I used S41squid.
Any thoughts why this occured?
Thank you
No there shouldn’t be a symlink.
There is an initscript for squid but it is run to start stop etc using a compiled c program binary called squidctrl which is called by the proxy.cgi code for the web proxy WUI page.
That is likely to mean that squid is being started but not the way it should be as it won’t be getting set up via the squidctrl program
squidctrl is located in /usr/local/bin/ and should have ownership and permissions as follows
ls -hal /usr/local/bin/squidctrl
-rwsr-x--- 1 root nobody 15K Jul 8 00:42 /usr/local/bin/squidctrl
Are the permissions and/or ownerships the same as these. If not then some corruption has occurred somewhere along the way, maybe during a Core Update.
The squid web proxy logs can be found on the WUI menu Logs - System Logs and then select Web Proxy in the drop down box marked section: and press the Update button. These log entries should give some clue as to what is occurring when squid is being started and failing before the symlink was created.
Researching this a bit more, it seems like this is something that others have seen in previous versions of ipfire - here is a thread that discusses this: Proxy problem after upgrade to core 155 - The proxy server is refusing connections - #37 by leozanon
There does not seem to be a resolution for this which is disappointing. What I find interesting is that if I start squid after a restart by using squidctrl (which calls /etc/init.d/squid) it starts reliably. Does anyone know what calls squidctrl at system boot? I would love to be able to get more verbose output to understand what the issue is
Thanks
A bug has been raised on this in the past
https://bugzilla.ipfire.org/show_bug.cgi?id=12623
Unfortunately no one on the IPFire devs has been able to reproduce the problem.
Maybe you can get involved in this bug and test out the known working proxy configuration mentioned in comment 13 by @pmueller and provide feedback on that.
Without getting some clues as to what is driving this issue for those experiencing it or how to reproduce the effect so it can be directly investigated by a dev it is very difficult to know what to go and change/fix.
I have had and still having issues with squid.
Rebooting would clear up the issue, but that took to long and the family noticed. So I dug in and found the various things that helped me to get back up and running faster. These may or may not help others with similar issues. The below quoted text I copied from an executable script file that I made called fix-network.sh Hopefully these issues will be resolved and I will not need it any more.
This network issues happen often enough that I keep an SSH session to IPFire open and up arrow once and the command is ready to be run with a press of the enter key.
#!
# run these 4 network status and restart cmds
#
for f in $(ls /var/log/messages* | sort -rV | tail -12) ; do fl=`ls -l $f`; zg=`zgrep -ic "SERVFAIL" $f`; printf "%s \t %s \n" "$fl" "$zg"; done
/etc/rc.d/init.d/squid status
/etc/rc.d/init.d/squid restart
/etc/init.d/network restart
#
#
echo " All Done for now! "
#
#
Nice script, but counting the “SERVFAIL” messages doesn’t really help without knowing the circumstances.
If I run your counting code, I get many hits also. But I know, that I’ve done some experiments on my WAN connections last months. So these errors are to be expected.
Bernhard, not knowing what the count means does make it difficult. I found that script on the ipfire community page somewhere and it helped me with my DNS issues of networking. Sometimes I have weekly numbers high and others low. I would rather no run any of it, but the network (squid at the moment) keeps stopping. 
Any way I understand it as clear as mud now. LOL
This is just referring the SERVFAIL counts and not the squid issue…
“counting the SERVFAIL” helps determine if there is a worry. If you have 100, 200, 300 SERVFAILs each and every week all is OK.
But if you have thousand(s) of SERVFAILs each and every week then it is time to look into.
I think the common way to fix thousand(s) SERVFAILs is to add another DNS server (a good one!) to the list. So if you have one or two, you may want three or four. I have four DNS servers. If I can find another good DNS server, I may add another.
Here is your SERVFAIL line with my SERVFAIL counts:
See the 4159 count for one week. That is not an issue since it goes back to normal the week after.
