Bug 12623 - Proxy problem since core 155 - The proxy server is refusing connections at machine startup
Summary: Proxy problem since core 155 - The proxy server is refusing connections at ma...
Status: ASSIGNED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: x86_64 All
: - Unknown - Major Usability
Assignee: Matthias Fischer
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-18 19:14 UTC by Panos Il
Modified: 2021-12-02 07:35 UTC (History)
4 users (show)

See Also:


Attachments
var-log-messages (9.67 KB, text/plain)
2021-06-01 09:46 UTC, Panos Il
Details
var-log-squid-cache_log (38.41 KB, text/plain)
2021-06-01 11:38 UTC, Panos Il
Details
Workaround: check and start squid via fcron.hourly (262 bytes, application/x-shellscript)
2021-12-02 07:24 UTC, Niva
Details
Workaround: check and start squid via fcron.hourly (262 bytes, text/plain)
2021-12-02 07:25 UTC, Niva
Details
Workaround: check and start squid via fcron.hourly (286 bytes, text/plain)
2021-12-02 07:32 UTC, Niva
Details
Workaround: check and start squid via fcron.hourly (286 bytes, text/plain)
2021-12-02 07:33 UTC, Niva
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Panos Il 2021-05-18 19:14:06 UTC
Since core 155, both on upgraded machines and on a new ipfire machine that was setup using core 155 iso, the proxy is refusing connections at startup. 

If I go to the IPFire web gui, Advanced web proxy configuration and click Save and Restart, then the proxy works normally and accepts connections.

I need to do this after every reboot/ startup.

All of the above are x64 physical machines.

I started a community thread here:
https://community.ipfire.org/t/proxy-problem-after-upgrade-to-core-155-the-proxy-server-is-refusing-connections/5020

It is also mentioned by another user in the thread that the issue is also present in core 156.
Comment 1 Michael Tremer 2021-05-25 11:23:43 UTC
Could you please provide log files? squid will probably tell us why it crashed.
Comment 2 Panos Il 2021-06-01 09:46:50 UTC
Created attachment 902 [details]
var-log-messages

I rebooted and after some time restarted the proxy service for web gui. I attach the /var/log/messages
Comment 3 Michael Tremer 2021-06-01 11:28:38 UTC
Could you please upload /var/log/squid/cache.log, too?
Comment 4 Panos Il 2021-06-01 11:38:53 UTC
Created attachment 903 [details]
var-log-squid-cache_log
Comment 5 Leonardo Zanon 2021-07-22 17:32:49 UTC
Hi,
I got this bug upgrading ipfire from 155 to 157.
(in the version 155 everything worked fine)

In my case, i noticed that enabling log management in GUI (before it was disabled) the service starts automatically during the boot phase, otherwise it doesnt.

Leonardo
Comment 6 Niva 2021-11-18 09:01:20 UTC
I have the same problem for a few months with an installation where several core updates have already been installed. Therefore I installed a system from scratch with Core 160 (without importing a backup). Unfortunately, I have to say that the problem occurs again with the new installation.
After restarting with "netstat -npl" I checked the open ports and determined that the proxy port (8080) is not open.
After "Save and restart" via the GUI, the port 8080 is open and the proxy works again.
I also have the entry:
Making directories in /var/log/cache/01
FATAL: Squid is already running: Found fresh instance PID file (/var/run/squid.pid) with PID 15433
    exception location: Instance.cc(121) ThrowIfAlreadyRunningWith


If this error is present, the missing in the cache log:
(what is available after the manual "save and restart")
Accepting HTTP Socket connections at local=x.x.x.x:8080

It should also be noted that the error occurs after an automatic restart via "Connection Scheduler" has taken place.
Comment 7 Michael Tremer 2021-11-18 11:16:19 UTC
@Matthias: Do you want to have a look at this?
Comment 8 Niva 2021-12-02 07:24:11 UTC
Created attachment 958 [details]
Workaround: check and start squid via fcron.hourly

I tested different settings.
Deactivate cache manager, hard disk cache size set to zero, URL filter deactivated. All without success, after a few days (1-3) the proxy service was not active during the night after an automatic restart (restart via the connection planner).

As a workaround I have now written myself a small script "check-squid" and run it every hour via fcron. This checks whether the proxy is running and starts it again if necessary.
At least that night the script worked. 

I copied the "check-squid" file to /etc/fcron.hourly and set the rights to rwxr-xr-x. After that there should be an entry "CheckSquid: ..." every hour under Logs -> System Logs -> Section:IPFire.
Perhaps this will also help others users as a temporary solution until the problem in the IPFire can be solved itself.
Comment 9 Niva 2021-12-02 07:25:43 UTC
Created attachment 959 [details]
Workaround: check and start squid via fcron.hourly

I tested different settings.
Deactivate cache manager, hard disk cache size set to zero, URL filter deactivated. All without success, after a few days (1-3) the proxy service was not active during the night after an automatic restart (restart via the connection planner).

As a workaround I have now written myself a small script "check-squid" and run it every hour via fcron. This checks whether the proxy is running and starts it again if necessary.
At least that night the script worked. 

I copied the "check-squid" file to /etc/fcron.hourly and set the rights to rwxr-xr-x. After that there should be an entry "CheckSquid: ..." every hour under Logs -> System Logs -> Section:IPFire.
Perhaps this will also help others users as a temporary solution until the problem in the IPFire can be solved itself.
Comment 10 Niva 2021-12-02 07:32:09 UTC
Created attachment 960 [details]
Workaround: check and start squid via fcron.hourly

I tested different settings.
Deactivate cache manager, hard disk cache size set to zero, URL filter deactivated. All without success, after a few days (1-3) the proxy service was not active during the night after an automatic restart (restart via the connection planner).

As a workaround I have now written myself a small script "check-squid" and run it every hour via fcron. This checks whether the proxy is running and starts it again if necessary.
At least that night the script worked.

I copied the "check-squid" file to /etc/fcron.hourly and set the rights to rwxr-xr-x. After that there should be an entry "CheckSquid: ..." every hour under Logs -> System Logs -> Section:IPFire.
Perhaps this will also help others users as a temporary solution until the problem in the IPFire can be solved itself.
Comment 11 Niva 2021-12-02 07:33:01 UTC
Created attachment 961 [details]
Workaround: check and start squid via fcron.hourly

I tested different settings.
Deactivate cache manager, hard disk cache size set to zero, URL filter deactivated. All without success, after a few days (1-3) the proxy service was not active during the night after an automatic restart (restart via the connection planner).

As a workaround I have now written myself a small script "check-squid" and run it every hour via fcron. This checks whether the proxy is running and starts it again if necessary.
At least that night the script worked.

I copied the "check-squid" file to /etc/fcron.hourly and set the rights to rwxr-xr-x. After that there should be an entry "CheckSquid: ..." every hour under Logs -> System Logs -> Section:IPFire.
Perhaps this will also help others users as a temporary solution until the problem in the IPFire can be solved itself.
Comment 12 Niva 2021-12-02 07:35:35 UTC
Sorry for the many entries.
I always got internal server error and tried several times as a result.