Squid not starting

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

1 Like

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


A bug has been raised on this in the past


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.