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