On 2026-03-26 09:34, Christoph Mathys wrote:
On Wed, Mar 4, 2026 at 7:32 PM Alex Rousskov wrote:
The devil is in the details. In this case, I suspect that at least two
details are relevant:
1. It is important to distinguish "Squid starts trying to connect" from
"Squid finishes trying to connect". Squid does not support multiple
_concurrent_ cache_peer probes. If a cache_peer probe takes, say, 30
seconds, the peer will be treated as dead for those 30 seconds. Roughly
speaking, another probe will be started when/if there is another
potential need for that cache_peer after the current probe finishes.
2. Probes that can mark a cache_peer as "alive" are not a part of a
regular HTTP transaction. They are triggered by regular transactions and
(re)configurations, but regular transactions do not _wait_ for probes to
finish and do not reuse probe connections. Probing is a "background"
activity.
That sound pretty reasonable. Can I tweak the 30s timeout?
N.B. I used "30 seconds" as an example of how long a probe might take.
That time accidentally matched peer_connect_timeout default.
peer_connect_timeout and related cache_peer options determine TCP probe
timeouts. See squid.conf.documented for that directive details. The
default for peer_connect_timeout global is 30 seconds. Please keep in
mind that peer_connect_timeout and related cache_peer options are _not_
specific to peer probes; they are used for regular TCP connection
opening attempts as well. Thus, if you decrease those timeouts, then
regular transactions may also be affected.
Or have
concurrent probes run so that later requests also immediately trigger
a probe?
No, there is no code to do that AFAICT. I doubt it should be added, and
adding it correctly would not be easy.
Adding peer_probe_timeout, a new squid.conf directive that you can use
to get a shorter connection establishment timeout for cache_peer probes,
may be a good idea though! That would be a relatively simple change AFAICT.
HTH,
Alex.
I observe the following on Mac OS:
Mac OS does not seem to sleep in the same way that an ACPI
Suspend-to-RAM sleeps: I see constant activity when I think it should
be sleeping. The VPN connection drops at some point during sleep or is
even directly terminated when the Mac enters sleep. Squid and
applications continue to run and generate log messages.
My log contains messages like the following about every hour:
2026/03/26 04:24:35| WARNING: DNS lookup for 'proxy4.example.com' failed!
current cache_peer probe: proxy4.example.com
2026/03/26 04:51:50| comm_udp_sendto FD 10, (family=2)
172.31.58.13:53: (51) Network is unreachable
current master transaction: master1203
2026/03/26 04:51:50| idnsSendQuery FD 10: sendto: (51) Network is unreachable
current master transaction: master1203
In the morning it need to restart squid because it seems that not
being able to resolve cache_peer is a bit of a red flag.
The same problem can happen when I close the Laptop, dropping VPN
through mobile, and then resume working inside the office without VPN.
Going forward, I see several paths:
A: Configure user devices to start Squid _after_ the user establishes "a
VPN connection to the corporate network". I do not know whether that is
possible in your environment, but, if it is, it would be a relatively
clean solution that does not require Squid development.
I currently delay starting squid until I can resolve a cache_peer.
This is only effective during boot. And of course, the user does not
always use VPN, but can also connect directly to the corporate WiFi
when at the office. So I think it is a bit messy to try to start and
stop squid at the right time.
B: Add a cache_peer "aggressive-probes" option to re-probe a still-DEAD
peer without waiting for an HTTP request that may use that peer. This
should be a fairly straightforward development project. This will not
solve all the problems[^B2], but it should help a lot.
I already hear the users complaining about battery drain. I think
triggering probing using a request is good enough in this case.
C: If you really want Squid to _stall/pause_ an incoming HTTP request
until at least one eligible cache_peer is available, then you will need
to write quite a bit of complicated code (AFAICT) that would be
difficult to make official. The idea just goes against how Squid peer
selection code is structured/designed. I do not recommend this path.
I don't think anything that drastic is required. Requests can just
fail until shortly after the VPN is connected (maybe 5-10s?).
Again, thank you very much for taking the time!
Christoph
_______________________________________________
squid-users mailing list
[email protected]
https://lists.squid-cache.org/listinfo/squid-users
