On 16/03/2017 7:05 p.m., Jens Offenbach wrote: > Thanks for your quick response... > > I have also configured, but the value seems not to be honored: > connect_timeout 30 seconds > > The primary peer is down, but Squid does not print any "Dead parent" > in the logs. Every HTTPS request is forwarded to the primary peer and > it takes 1 minute until the secondary peer gets used, even with > "connect_timeout 30 seconds". I think, I am facing the first issue > that has been fixed by your patch. > The global config options being ignored completely is correct because your peer have individual connect-timeout=5 settings. So, those 5sec timeouts should be used instead now as before. Though note that they apply only to how long a TCP connection (SYN, SYN-ACK) is waited for. There is also a dns_timeout and peer selection timeout that apply separately to the act of connecting. And a forward_timeout global limit that all those operations have to fit within, including retries. Did you have a chance to try the debug setting I suggested at the beginning? That will give you an immediate view about what Squid is detecting as usable paths for each and every request and at what times relative to the DEAD/LIVE notice. > Are there any plans to backport this fix to Xenial APT repositories > or to create a new Debian package for Squid4/5? That is up to the Ubuntu server team, but I think it Unlikely. Zesty is the current stable and things like this generally dont have enough widespread impact to qualify for LTS backports. Debian is now frozen to stabilize for the "Buster" release, that will contain Squid-3.5.23 plus some few critical patches which are already set. A Squid-4 package is ready and waiting for the release freeze to end before it goes public in the Debian Unstable/Testing repos. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
