<div dir="auto">Maybe its apparmor.<div dir="auto">pinger needs to have a setuid permission as root.</div><div dir="auto">its a pinger and needs root privleges as far as i remember.</div><div dir="auto"><br></div><div dir="auto">Eliezer</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 9, 2021, 17:03 Chris <<a href="mailto:ml%2Bsquidusers@kisswebdev.com">ml+squidusers@kisswebdev.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
thank you Amos, this is bringing me into the right direction.<br>
<br>
Now I know what I'll have to debug: the pinger.<br>
<br>
Cache.log shows:<br>
<br>
2021/02/09 14:49:27| pinger: Initialising ICMP pinger ...<br>
2021/02/09 14:49:27| pinger: ICMP socket opened.<br>
2021/02/09 14:49:27| pinger: ICMPv6 socket opened<br>
2021/02/09 14:49:27| Pinger exiting.<br>
<br>
and that last line "pinger exiting" looks like a problem here.<br>
<br>
Squid is used as a package from ubuntu bionic, it's configured with <br>
"--enable-icmp" as stated by squid -v.<br>
<br>
Now I explicitly wrote a "pinger_enable on" and the pinger_program path <br>
(in this case: "/usr/lib/squid/pinger" ) into the squid.conf  (as well <br>
as icmp_query on) and reconfigured but the cache.log still shows:<br>
<br>
"Pinger exiting"<br>
<br>
So I don't understand why the pinger is exiting. The pinger_program is <br>
owned by root and has 0755 execution rights. Normal ping commands do <br>
work and show the one originserver at ttl=53 and time=50 while the other <br>
is at ttl=56 and time=155 - so a RTT comparison for weighted-round-robin <br>
should work here.<br>
<br>
Any hints on how I can find out why the pinger is exiting? Right now I'm <br>
debuging with debug_options ALL,1 44,3 15,8 but don't see a reason why <br>
the pinger exits.<br>
<br>
The Originservers are defined by (with icp/htcp disabled):<br>
<br>
cache_peer [ipv4_address_srv1] parent [http_port] 0 no-digest <br>
no-netdb-exchange weighted-round-robin originserver name=srv1 <br>
forceddomain=[domainname]<br>
<br>
cache_peer [ipv4_address_srv2] parent [http_port] 0 no-digest <br>
no-netdb-exchange weighted-round-robin originserver name=srv2 <br>
forceddomain=[domainname]<br>
<br>
<br>
Thank you for your help,<br>
<br>
Chris<br>
<br>
<br>
<br>
<br>
<br>
On 09.02.21 04:23, Amos Jeffries wrote:<br>
> On 9/02/21 3:40 am, Chris wrote:<br>
>> Hi all,<br>
>><br>
>> I'm trying to figure out the best way to use squid (version 3.5.27) <br>
>> in reverse proxy mode in regard to originserver health checks and <br>
>> load balancing.<br>
>><br>
>> So far I had been using the round-robin originserver cache peer <br>
>> selection algorithm while using weight to favor originservers with <br>
>> closer proximity/lower latency.<br>
>><br>
><br>
> Ok.<br>
><br>
><br>
>> The problem: if one cache_peer is dead it takes ages for squid to <br>
>> choose the second originserver. It does look as if (e.g. if one <br>
>> originserver has a weight of 32, the other of 2) squid tries the dead <br>
>> server several times before accessing the other one.<br>
>><br>
><br>
> The DEAD check by default requires 10 failures in a row to trigger. <br>
> This is configurable with the connect-fail-limit=N option.<br>
><br>
><br>
>> Now instead of using round-robin plus weight it would be best to use <br>
>> weighted-round-robin. But as I understand it, this wouldn't work with <br>
>> originserver if (as it's normally the case) the originserver won't <br>
>> handle icp or htcp requests. Did I miss sth. here? Would <br>
>> background-ping work?<br>
><br>
> Well, kind of.<br>
><br>
> ICP/HTCP is just a protocol. Most origin servers do not support them, <br>
> but some do. Especially if the server is not a true origin but a <br>
> reverse-proxy.<br>
><br>
><br>
>><br>
>> I tried weighted-round-robin and background-ping on originservers but <br>
>> got only an evenly distributed request handling even if ones <br>
>> originservers rtt would be less than half of the others. But then <br>
>> again, those originservers won't handle icp requests.<br>
><br>
> RTT is retrieved from ICMP data primarily. Check your Squid is built <br>
> with --enable-icmp, the pinger helper is operational, and that ICMP <br>
> Echo traffic is working on all possible network routes between your <br>
> Squid and the peer server(s).<br>
><br>
><br>
>><br>
>> So what's the best solution to a) choose the originserver with the <br>
>> lowest rtt and b) still have a fast switch if one of the <br>
>> originservers switches into dead state?<br>
><br>
><br>
> Check whether the RTT is actually being measured properly by Squid <br>
> (debug_options ALL,1 44,3 15,8). If the peers are fast enough <br>
> responding or close enough in the network RTT could come out as a 0 <br>
> value or some N value equal for both peer. ie. neither being "closer".<br>
><br>
><br>
> Amos<br>
> _______________________________________________<br>
> squid-users mailing list<br>
> <a href="mailto:squid-users@lists.squid-cache.org" target="_blank" rel="noreferrer">squid-users@lists.squid-cache.org</a><br>
> <a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org" target="_blank" rel="noreferrer">squid-users@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
</blockquote></div>