Re: [squid-users] squid -k rec , seems has problem with ram leakage ?

2018-02-27 Thread Eliezer Croitoru 
Thanks Amos,

It might not be my place to say a word but 100 instances on a single machine 
can only be good for specific cases which he might have under his hands.

I believe that in such cases on the long term he might need a better solution 
but it's not my place to lectures anyone.

Eliezer


Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il



-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Amos Jeffries
Sent: Wednesday, February 28, 2018 06:17
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] squid -k rec , seems has problem with ram leakage ?

On 23/02/18 06:46, Eliezer Croitoru wrote:
> Hey Ahmad,
> 
> I’m not sure I understand what 100 instances of squid means?


IIRC, he is using the Squid "-n" feature.

You may know it as "multi-tenant". Running multiple of the "Squid
instance" as defined at
 within the
same OS environment.


( "${service_name}" usage in this thread squid.conf is the big clue
here. But I am basing my IIRC on older threads across the last year when
he was asking for help on how to set it up. )


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

Re: [squid-users] squid -k rec , seems has problem with ram leakage ?

2018-02-27 Thread Amos Jeffries 
On 23/02/18 06:46, Eliezer Croitoru wrote:
> Hey Ahmad,
> 
> I’m not sure I understand what 100 instances of squid means?


IIRC, he is using the Squid "-n" feature.

You may know it as "multi-tenant". Running multiple of the "Squid
instance" as defined at
 within the
same OS environment.


( "${service_name}" usage in this thread squid.conf is the big clue
here. But I am basing my IIRC on older threads across the last year when
he was asking for help on how to set it up. )


Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] help with the error TCP_MISS_ABORTED/000

2018-02-27 Thread L A Walsh 

Juan Manuel P wrote:
I am using Squid Cache: Version 3.5.12, but some pages give me the 
next error:


1/Feb/2018:18:14:40 -0300 || - || 10.12.43.20 || 
TCP_MISS_ABORTED/000|| GET || 
http://www.rionegro.gov.ar/download/images/00033494.jpg 
 || -


   I don't know what causes it, but I see it frequently and have for a few
years.  Currently am running 3.15.3.  Was told it might be due to some
cache corruption -- but having removed it several times over the past
few years, I sorta doubt that.  Also, I'm attempting https interception, now
but wasn't when I first encountered this message...

   Out of last 5000 requests in my squid log, I see 101 of the miss_aborted
statuses.  I just wrote a note on stackexchange, then went to look for
something on amazon (this is output from a squid log compression tool
that was mostly for listing site, request time and size:  A few lines
from no more than 15 minutes ago (usually shows time between requests, but
periodically, there's a full timestamp)...

   Part of my shortening process removes the TCP_ before error messages,
thus my error is just "MISS_ABORTED".

Since this is a grep of that shortened log, the time increments since
last message are not referring to line immediately above in the grep:


[0227_172940.00]  379ms; 0(0/0) MISS_ABORTED/000 https://qa.sockets.stackexchange.com/ - 198.252.206.25 -]
 +0.38   372ms; 0(0/0) MISS_ABORTED/000 https://qa.sockets.stackexchange.com/ - 198.252.206.25 -]
 +0.01 1ms; 0(0/0) MISS_ABORTED/000 https://images-na.ssl-images-amazon.com/images/I/61x0MG3xpeL._AC_UL160_SR160,160_.jpg 
- 54.230.117.34 -]
 +0.00 0ms; 0(-/-) MISS_ABORTED/000 https://images-na.ssl-images-amazon.com/images/I/813zL5eetaL._AC_UL160_SR160,160_.jpg 
- 54.230.117.34 -]
 +0.00 0ms; 0(-/-) MISS_ABORTED/000 https://images-na.ssl-images-amazon.com/images/I/61Uo2hXZlpL._AC_UL160_SR160,160_.jpg 
- 54.230.117.34 -]
 +0.00 0ms; 0(-/-) MISS_ABORTED/000 https://images-na.ssl-images-amazon.com/images/I/71XggjYZ7qL._AC_UL160_SR160,160_.jpg 
- 54.230.117.34 -]
 +0.00 1ms; 0(-/0) MISS_ABORTED/000 https://images-na.ssl-images-amazon.com/images/I/71LT8PAs-OL._AC_UL160_SR160,160_.jpg 
- 54.230.117.34 -]
 +0.00 1ms; 0(-/0) MISS_ABORTED/000 https://images-na.ssl-images-amazon.com/images/I/51X+70QICxL._AC_UL160_SR160,160_.jpg 
- 54.230.117.34 -]
[0227_173215.00]   16ms; 0(0/0) MISS_ABORTED/000 https://www.amazon.com/gp/uedata?ul=0.200071.0=TXSV6J9MMKFJ764232PB=1=1=TXSV6J9MMKFJ764232PB=3758697=-286=1=3=3758697=1519781535329=mouseHit=Detail=Glance=B079GH97R9=TXSV6J9MMKFJ764232PB=1 
- 23.192.244.68 -]




Of note -- a bunch were in trying to fetch a sockets address on 
stackexchange, , while most of the amazon lines seem to be referring to 
jpgs.  Anyway, I too would be interested if you find the answer.


Just thought I'd mention that your seeing the message isn't unique.

Found someone else who asked the same question back in May 2015...


___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Kerberos negotiate slow avg service time

2018-02-27 Thread Amos Jeffries 
On 28/02/18 07:43, erdosain9 wrote:
> Thank you Amos (sorry again Yuri).
> 
> And yes, the user are complains.
> 
> The problem is this (and sorry for be recurrent with this).
> 
> That value avg ms for some times goes up to 3000... and in that moment all
> stop.
> 
> in the cache.log sometimes, im getting this.
> 
> support_sasl.cc(276): pid=3729 :2018/02/27 14:44:35| kerberos_ldap_group:
> ERROR: ldap_sasl_interactive_bind_s error: Can't contact LDAP server
> support_ldap.cc(957): pid=3729 :2018/02/27 14:44:35| kerberos_ldap_group:
> ERROR: Error while binding to ldap server with SASL/GSSAPI: Can't contact
> LDAP server
> 2018/02/27 14:44:49 kid1| Error negotiating SSL on FD 45:
> error::lib(0):func(0):reason(0) (5/-1/104)
> support_sasl.cc(276): pid=3719 :2018/02/27 14:46:56| kerberos_ldap_group:
> ERROR: ldap_sasl_interactive_bind_s error: Can't contact LDAP server
> support_ldap.cc(957): pid=3719 :2018/02/27 14:46:56| kerberos_ldap_group:
> ERROR: Error while binding to ldap server with SASL/GSSAPI: Can't contact
> LDAP server
> support_sasl.cc(276): pid=3719 :2018/02/27 14:47:18| kerberos_ldap_group:
> ERROR: ldap_sasl_interactive_bind_s error: Can't contact LDAP server
> support_ldap.cc(957): pid=3719 :2018/02/27 14:47:18| kerberos_ldap_group:
> ERROR: Error while binding to ldap server with SASL/GSSAPI: Can't contact
> LDAP server
> support_sasl.cc(276): pid=3729 :2018/02/27 14:47:28| kerberos_ldap_group:
> ERROR: ldap_sasl_interactive_bind_s error: Can't contact LDAP server
> support_ldap.cc(957): pid=3729 :2018/02/27 14:47:28| kerberos_ldap_group:
> ERROR: Error while binding to ldap server with SASL/GSSAPI: Can't contact
> LDAP server
> support_sasl.cc(276): pid=3719 :2018/02/27 14:47:36| kerberos_ldap_group:
> ERROR: ldap_sasl_interactive_bind_s error: Can't contact LDAP server
> support_ldap.cc(957): pid=3719 :2018/02/27 14:47:36| kerberos_ldap_group:
> ERROR: Error while binding to ldap server with SASL/GSSAPI: Can't contact
> LDAP server
> 
> 
> Is impossible that this problem happend from the squid side? Im thinking
> that is a problem in the AD (windows server 2012).

The Squid helper is using a SASL library on your system to contact the
LDAP server. Those error messages are sadly all the info which Squid or
its helper have about the failure.

A quick search for the message though, brings up this document about
LDAP listing quite a few reasons that message may appear (ie places to
check):
 

Note: I have no knowledge of its accuracy, it just seems like a useful
list of things for you to check up on.

From the sounds of it the problem is usually a lot more harsh and fatal
than what yo are seeing. It is kind of odd that it only affects an
occasional request - as shown by your cachemgr report earlier *most*
requests go straight through nice and quickly.


This may be quite different, but: I saw similar weird "sometimes"
failures with an IMAP service last year. It turned out that fail2ban was
set with a slightly too-low threshold and was banning a particular
client on flakey Dial-Up internet connection when it was raining in
their neighbourhood. Their TCP connection losses caused a ban which we
were seeing only as failure to re-login some minutes later once the
clients mail program wanted to re-check new mail.



> 
> With more log (-d) i got a lot of this... (just a little). This is working
> negotiate_kerberos_pac.cc(376): pid=3973 :2018/02/27 12:08:33|
> negotiate_kerberos_auth: INFO: Got PAC data of lengh 584
> negotiate_kerberos_pac.cc(180): pid=3973 :2018/02/27 12:08:33|
> negotiate_kerberos_auth: INFO: Found 4 rids
> negotiate_kerberos_pac.cc(188): pid=3973 :2018/02/27 12:08:33|
> negotiate_kerberos_auth: Info: Got rid: 1168
> negotiate_kerberos_pac.cc(188): pid=3973 :2018/02/27 12:08:33|
> negotiate_kerberos_auth: Info: Got rid: 512
> negotiate_kerberos_pac.cc(188): pid=3973 :2018/02/27 12:08:33|
> negotiate_kerberos_auth: Info: Got rid: 513
> negotiate_kerberos_pac.cc(188): pid=3973 :2018/02/27 12:08:33|
> negotiate_kerberos_auth: Info: Got rid: 1132
> negotiate_kerberos_pac.cc(256): pid=3973 :2018/02/27 12:08:33|
> negotiate_kerberos_auth: INFO: Got DomainLogonId
> S-1-5-21-3939648023-1419124151
> -3306617744
> negotiate_kerberos_pac.cc(278): pid=3973 :2018/02/27 12:08:33|
> negotiate_kerberos_auth: INFO: Found 1 ExtraSIDs
> negotiate_kerberos_pac.cc(327): pid=3973 :2018/02/27 12:08:33|
> negotiate_kerberos_auth: INFO: Got ExtraSid S-1-18-1
> negotiate_kerberos_pac.cc(456): pid=3973 :2018/02/27 12:08:33|
> negotiate_kerberos_auth: INFO: Read 540 of 584 bytes 
> negotiate_kerberos_auth.cc(778): pid=3973 :2018/02/27 12:08:33|
> negotiate_kerberos_auth: DEBUG: Groups
> group=AQUAAAUVF0LS6rcdllSQ+xbFk
> AQAAA== group=AQUAAAUVF0LS6rcdllSQ+xbFAAIAAA==
> group=AQUAAAUVF0LS6rcdllSQ+xbFAQIAAA==
> group=AQUAAAUVF0LS6rcdllSQ+xbFbA
> QAAA== group=AQEAABIB
> negotiate_kerberos_auth.cc(783): pid=3973

Re: [squid-users] Kerberos negotiate slow avg service time

2018-02-27 Thread erdosain9 
Thank you Amos (sorry again Yuri).

And yes, the user are complains.

The problem is this (and sorry for be recurrent with this).

That value avg ms for some times goes up to 3000... and in that moment all
stop.

in the cache.log sometimes, im getting this.

support_sasl.cc(276): pid=3729 :2018/02/27 14:44:35| kerberos_ldap_group:
ERROR: ldap_sasl_interactive_bind_s error: Can't contact LDAP server
support_ldap.cc(957): pid=3729 :2018/02/27 14:44:35| kerberos_ldap_group:
ERROR: Error while binding to ldap server with SASL/GSSAPI: Can't contact
LDAP server
2018/02/27 14:44:49 kid1| Error negotiating SSL on FD 45:
error::lib(0):func(0):reason(0) (5/-1/104)
support_sasl.cc(276): pid=3719 :2018/02/27 14:46:56| kerberos_ldap_group:
ERROR: ldap_sasl_interactive_bind_s error: Can't contact LDAP server
support_ldap.cc(957): pid=3719 :2018/02/27 14:46:56| kerberos_ldap_group:
ERROR: Error while binding to ldap server with SASL/GSSAPI: Can't contact
LDAP server
support_sasl.cc(276): pid=3719 :2018/02/27 14:47:18| kerberos_ldap_group:
ERROR: ldap_sasl_interactive_bind_s error: Can't contact LDAP server
support_ldap.cc(957): pid=3719 :2018/02/27 14:47:18| kerberos_ldap_group:
ERROR: Error while binding to ldap server with SASL/GSSAPI: Can't contact
LDAP server
support_sasl.cc(276): pid=3729 :2018/02/27 14:47:28| kerberos_ldap_group:
ERROR: ldap_sasl_interactive_bind_s error: Can't contact LDAP server
support_ldap.cc(957): pid=3729 :2018/02/27 14:47:28| kerberos_ldap_group:
ERROR: Error while binding to ldap server with SASL/GSSAPI: Can't contact
LDAP server
support_sasl.cc(276): pid=3719 :2018/02/27 14:47:36| kerberos_ldap_group:
ERROR: ldap_sasl_interactive_bind_s error: Can't contact LDAP server
support_ldap.cc(957): pid=3719 :2018/02/27 14:47:36| kerberos_ldap_group:
ERROR: Error while binding to ldap server with SASL/GSSAPI: Can't contact
LDAP server


Is impossible that this problem happend from the squid side? Im thinking
that is a problem in the AD (windows server 2012). 

With more log (-d) i got a lot of this... (just a little). This is working
negotiate_kerberos_pac.cc(376): pid=3973 :2018/02/27 12:08:33|
negotiate_kerberos_auth: INFO: Got PAC data of lengh 584
negotiate_kerberos_pac.cc(180): pid=3973 :2018/02/27 12:08:33|
negotiate_kerberos_auth: INFO: Found 4 rids
negotiate_kerberos_pac.cc(188): pid=3973 :2018/02/27 12:08:33|
negotiate_kerberos_auth: Info: Got rid: 1168
negotiate_kerberos_pac.cc(188): pid=3973 :2018/02/27 12:08:33|
negotiate_kerberos_auth: Info: Got rid: 512
negotiate_kerberos_pac.cc(188): pid=3973 :2018/02/27 12:08:33|
negotiate_kerberos_auth: Info: Got rid: 513
negotiate_kerberos_pac.cc(188): pid=3973 :2018/02/27 12:08:33|
negotiate_kerberos_auth: Info: Got rid: 1132
negotiate_kerberos_pac.cc(256): pid=3973 :2018/02/27 12:08:33|
negotiate_kerberos_auth: INFO: Got DomainLogonId
S-1-5-21-3939648023-1419124151
-3306617744
negotiate_kerberos_pac.cc(278): pid=3973 :2018/02/27 12:08:33|
negotiate_kerberos_auth: INFO: Found 1 ExtraSIDs
negotiate_kerberos_pac.cc(327): pid=3973 :2018/02/27 12:08:33|
negotiate_kerberos_auth: INFO: Got ExtraSid S-1-18-1
negotiate_kerberos_pac.cc(456): pid=3973 :2018/02/27 12:08:33|
negotiate_kerberos_auth: INFO: Read 540 of 584 bytes 
negotiate_kerberos_auth.cc(778): pid=3973 :2018/02/27 12:08:33|
negotiate_kerberos_auth: DEBUG: Groups
group=AQUAAAUVF0LS6rcdllSQ+xbFk
AQAAA== group=AQUAAAUVF0LS6rcdllSQ+xbFAAIAAA==
group=AQUAAAUVF0LS6rcdllSQ+xbFAQIAAA==
group=AQUAAAUVF0LS6rcdllSQ+xbFbA
QAAA== group=AQEAABIB
negotiate_kerberos_auth.cc(783): pid=3973 :2018/02/27 12:08:33|
negotiate_kerberos_auth: DEBUG: AF
oYG2MIGzoAMKAQChCwYJKoZIgvcSAQICooGeBIGbYIG
YBgkqhkiG9xIBAgICAG+BiDCBhaADAgEFoQMCAQ+ieTB3oAMCARKicARub5MOjpO177M/gXJcAdluTnj+29wfwmcbZJVIFDyiXBKLScmwPhaPd2sH4IvcEiBhgddiTbURTRfM7OsWlql7+
uS2I4WWSke5bcRYRIaprvgl3wtCoX9PjSQEmYL0H8LIBL0sQh2fbYftAXyxMGs=
u...@mydomain.lan
negotiate_kerberos_auth.cc(610): pid=3973 :2018/02/27 12:08:37|
negotiate_kerberos_auth: DEBUG: Got 'YR
YIIHJQYGKwYBBQUCoIIHGTCCBxWgMDAuBgkqhk
iC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCBt8EggbbYIIG1wYJKoZIhvcSAQICAQBuggbGMIIGwqADAgEFoQMCAQ6iBwMFACCjggUDYYIE/zCCBPug
AwIBBaEMGwpFTVBEREguTEFOoiMwIaADAgECoRowGBsESFRUUBsQcHJveHkuZW1wZGRoLmxhbqOCBL8wggS7oAMCARKhAwIBA6KCBK0EggSpV5Ofs3WVdVBcsFv+Hm0rIqwv8Lnra2qZOa
8cldCaPT4j6lGbmhe4JphrdI8H+dJbZI42SC1WLj6ettPI1OB5JPc340A6q3X7f9Zjp1rplc/6/n2mNooCah+Epq83CeI2w1bjX24sIwv5Vj5fNv9l5tzRI2vm5hry828+jNNGEamR0Vi5
1wy1HpFRVm39xExs9HiIdVRuVLC2sgXPf3PLLlmE5pKPATPW074v045VnrYXFERgyFN45Le4oBqavwtQ4yxdnVt/3wHzx9B2jYckYp0EMbS4yHMH8trwNJwYWji7zTINkD1s81EMCl0t0R
bQBwt8rLbcYLurOpj95nicRZbfSAkNozbVo1i4sYApjqxZG1xPK1JdNYc927kCayiTSa6emuD2LbXaY47phntoGg77k8JvaSeqL/yNMhPS8/k5PuE1qSaQjSvatAiqUF8fWQRu9O8f4uhQ
LyseKPkBiO6Ll/NgQFXhAQOwxyvunbLZhVz568UsP1EMw8IRU8m6CRXoyHB9xFQVS+QI3PBYXzD3eFtYfofbXJjYm97VZrB+CmmU5K72Azm/bQzwybSbDhqLo9FyKAR2K9lFp0q3/Gt/Gf