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+squidus...@kisswebdev.com> 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@lists.squid-cache.org > > http://lists.squid-cache.org/listinfo/squid-users > _______________________________________________ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users >
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
