From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] squid: Update to 4.4 (stable) Date: Fri, 21 Dec 2018 15:28:29 +0100 Message-ID: In-Reply-To: <76d5c380-d4e5-f053-6d92-630affd8f4cc@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6697654183906536697==" List-Id: --===============6697654183906536697== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey, > On 20 Dec 2018, at 21:05, Matthias Fischer = wrote: >=20 > Hi, >=20 > On 19.12.2018 18:54, Matthias Fischer wrote: >> On 19.12.2018 18:46, Michael Tremer wrote: >>> Hi, >>>=20 >>>> On 19 Dec 2018, at 17:45, Matthias Fischer wrote: >>>>=20 >>>> Hi Michael, >>>>=20 >>>> On 19.12.2018 17:10, Michael Tremer wrote: >>>>> Sorry from me as well for overlooking that. >>>>=20 >>>> No problem... ;-) >>>>=20 >>>>> Merged and the nightly build ran through=E2=80=A6 >>>>=20 >>>> Ok, thanks for the feedback - in between I thought there were still >>>> mistakes in it. That d*** "binary blob" came from my installation >>>> archive - I forgot to delete it *twice* before pushing! Duh! Now I'm >>>> using a dedicated 'upload'-directory for these archives, so this won't >>>> happen again=E2=80=A6 >>>>=20 >>> No worries. Shit happens. >>>=20 >>>> On my production machine this build is running without any errors since >>>> then. >>>=20 >>> Good. I will install this as soon as possible. I still don=E2=80=99t quit= e believe that nothing in the configuration has to be changed. >>=20 >> 'squid - k parse' never showed any errors and the GUI didn't make any >> problems until now. We'll see. >>=20 >>> We still have Daniel=E2=80=99s patch that hasn=E2=80=99t been integrated.= Do you have time to look into that again, too? I forget where that got stuck= =E2=80=A6 >>=20 >> I can do that - its running here - work in progress. ;-) >=20 > I fear I've found ONE problem with Daniel's patch and the > 'queue-size'-option, so I'd prefer to alter the 'queue-size'-value from > '64' to '128=E2=80=99. Hmm, 64 was just a guess. That=E2=80=99s definitely debatable. > With 'queue-size=3D64' I got these errors again today: >=20 > ... > 2018/12/20 11:17:49 kid1| comm_udp_sendto FD 8, (family=3D2) 127.0.0.1:53: > (1) Operation not permitted > 2018/12/20 11:17:49 kid1| idnsSendQuery FD 8: sendto: (1) Operation not > permitted > 2018/12/20 11:17:54 kid1| comm_udp_sendto FD 8, (family=3D2) 127.0.0.1:53: > (1) Operation not permitted > 2018/12/20 11:17:54 kid1| idnsSendQuery FD 8: sendto: (1) Operation not > permitted > 2018/12/20 11:18:04 kid1| comm_udp_sendto FD 8, (family=3D2) 127.0.0.1:53: > (1) Operation not permitted > 2018/12/20 11:18:04 kid1| idnsSendQuery FD 8: sendto: (1) Operation not > permitted > ... >=20 > They happen even without any DNS rules - perhaps the '64' is too small!? This is just a problem resolving the hostname. Either that is because there i= s a firewall rule that blocks port 53 (unlikely) or unbound hits a limit of m= aximum number of requests per host. In that case we probably need to adjust t= hat. You should be able to trace that with tcpdump: tcpdump -i lo port 53 -nn There is probably TCP reset packets (with an R in the square brackets). > With '128' I don't see them. Any thoughts? If my theory above this true, this does not make much sense. So either I am w= rong or this changes some other behaviour too. No matter how long the queue, = the number of requests processed at a time should be the same. Best, -Michael >=20 > Best, > Matthias --===============6697654183906536697==--