Re: [squid-users] QUID stops responding intermittently.

On Thu, 22 Oct 2009 17:11:38 +0500, "Asim Ahmed @ Folio3"
<aahmed_at_folio3.com> wrote:
> problem still there. My Squid still resets every 2 mins or even less
> than that. it stops accepting connections and automatically start again.

> becoming a pain. following is my squid.conf. I m running Squid
> 3.0Stable16 on RHEL5 with 2 GB RAM on Pentium D 2.4 GHz. It is totally
> random when it starts and stops.

Sure sign of something major going wrong and killing Squid.
The reason is in cache.log just above a line starting with FATAL:

> Even reboot / restart of squid does not
> make any difference. Any help would be appriciated.
>
> acl manager proto cache_object
> acl localhost src 127.0.0.1/32
> acl to_localhost dst 127.0.0.0/8
> acl SSL_ports port 443
> acl Safe_ports port 80 # http
> acl Safe_ports port 21 # ftp
> acl Safe_ports port 443 # https
> acl Safe_ports port 70 # gopher
> acl Safe_ports port 210 # wais
> acl Safe_ports port 1025-65535 # unregistered ports
> acl Safe_ports port 280 # http-mgmt
> acl Safe_ports port 488 # gss-http
> acl Safe_ports port 591 # filemaker
> acl Safe_ports port 777 # multiling http
> acl CONNECT method CONNECT
> acl Folio3_Network src 192.168.4.0/24 # RFC1918 possible internal
> network
> acl WorkingHours time M T W H F 9:00-19:00

... still broken with whitespaces in the day spec.

> acl BadSites dstdomain "/etc/squid/restricted_sites.list"
> http_access allow manager localhost
> http_access deny manager
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access deny BadSites WorkingHours
> http_access allow Folio3_Network
> http_access allow localhost
> http_access deny all
> icp_access allow Folio3_Network
> icp_access deny all
> htcp_access allow Folio3_Network
> htcp_access deny all
> reply_body_max_size 5 MB
> http_port 3128 transparent
> hierarchy_stoplist cgi-bin ?
> cache_mem 512 MB
> cache_dir aufs /var/spool/squid 10240 16 256
> cache_swap_low 90
> cache_swap_high 92
> access_log /var/log/squid/access.log squid
> refresh_pattern ^ftp: 1440 20% 10080
> refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern (cgi-bin|\?) 0 0% 0
> refresh_pattern . 0 20% 4320
> shutdown_lifetime 5 seconds
> visible_hostname folio3.gateway.102
> icp_port 3130
> coredump_dir /var/spool/squid
>
> -Asim Ahmed
>
> Asim Ahmed @ Folio3 wrote:
>> Hi Amos,
>>
>> Thanks for your quick help. I am using following (I suppose latest
>> available series) of Squid
>>
>> Index of /jskala/squid/squid-3.0.STABLE16-1.el5/i386
>>
>> I've made those ufs/aufs changes & cache_low/high in squid.conf. I'll
>> let you know about the feedback soon. Also I've removed spaces from
>> time ACL elements MTWHF ...
>>
>> -Asim Ahmed
>>
>> Amos Jeffries wrote:
>>> On Tue, 20 Oct 2009 19:53:02 +0500, "Asim Ahmed @ Folio3"
>>> <aahmed_at_folio3.com> wrote:
>>>
>>>> -
>>>>
>>>> Hi all,
>>>>
>>>> I have installed Squid 3.0 STABLE on RHEL5. I am using it on
>>>> conjunction
>>>>
>>>
>>>
>>> 3.0STABLE what? there are now around 21 releases in circulation.
>>>
>>>
>>>> with Shorewall 4.4.2.2. I've tested that Shorewall is working fine
>>>> on machine. The problem is that SQUID stops responding
>>>> intermittently. This
>>>>
>>>
>>>
>>>> period ranges from minuts / hours / days. Some time it works
>>>> absolutely fine and at other times it just dies. Even "tail -f
>>>> access.log" does not
>>>>
>>>
>>>
>>>> show any activity at all. Internet stops working.
>>>>
>>>> Machine is Pentium D 2.0 GHz with 2 GB of RAM. Out of my squid.conf
>>>> through *grep -v "^#" /etc/squid/squid.conf | sed -e '/^$/d'* is
>>>>
>>>> acl manager proto cache_object
>>>> acl localhost src 127.0.0.1/32
>>>> acl to_localhost dst 127.0.0.0/8
>>>> acl localnet src 192.168.4.0/24 # RFC1918 possible internal network
>>>> acl Safe_ports port 80 # http
>>>> acl Safe_ports port 21 # ftp
>>>> acl Safe_ports port 443 # https
>>>> acl Safe_ports port 70 # gopher
>>>> acl Safe_ports port 210 # wais
>>>> acl Safe_ports port 1025-65535 # unregistered ports
>>>> acl Safe_ports port 280 # http-mgmt
>>>> acl Safe_ports port 488 # gss-http
>>>> acl Safe_ports port 591 # filemaker
>>>> acl Safe_ports port 777 # multiling http
>>>> acl CONNECT method CONNECT
>>>> acl BusinessHours time M T W H F 9:00-13:00
>>>> acl BusinessHours time M T W H F 14:30-19:00
>>>>
>>>
>>> The above should have no spaces in the day specifier: MTWHF
>>>
>>>
>>>> acl BadSites dstdomain "/etc/squid/restricted_sites.list"
>>>> http_access allow manager localhost
>>>> http_access deny manager
>>>> http_access deny !Safe_ports
>>>> http_access deny BadSites BusinessHours
>>>> http_access allow localnet
>>>> http_access deny all
>>>> icp_access allow localnet
>>>> icp_access deny all
>>>> htcp_access allow localnet
>>>> htcp_access deny all
>>>> reply_body_max_size 5 MB
>>>> http_port 46095 transparent
>>>> include /etc/squid/mediatypes.list
>>>> hierarchy_stoplist cgi-bin ?
>>>> cache_mem 256 MB
>>>> cache_dir ufs /var/spool/squid 16384 16 256
>>>>
>>>
>>> This is probably the cause. UFS file system is extremely slow. Also
>>> with
>>>
>>>> 10GB the default garbage collection settings for 3.0 are too wide.
>>>> Squid
>>>>
>>> can block up while removing 5% of the cached files once an hour.
>>>
>>> I recommend setting:
>>> cache_dir aufs /var/spool/squid 16384 16 256
>>> cache_swap_low 90
>>> cache_swap_high 92
>>>
>>>
>>> Also,,,,
>>>
>>> check cache.log for signs of squid dying. Restarting and reloading a
>>> large cache through slow disk IO systems can cause a few dozen seconds
>>> delay in request handling.
>>>
>>> please use the latest release available (there are current
'unofficial'
>>> packages for RHEL in the www.squid-cache.org binary downloads pages).
>>>
>>>
>>>
>>>> access_log /var/log/squid/access.log squid
>>>> refresh_pattern ^ftp: 1440 20% 10080
>>>> refresh_pattern ^gopher: 1440 0% 1440
>>>> refresh_pattern (cgi-bin|\?) 0 0% 0
>>>> refresh_pattern . 0 20% 4320
>>>> shutdown_lifetime 5 seconds
>>>> visible_hostname gateway.folio3.com
>>>> icp_port 3130
>>>> coredump_dir /var/spool/squid
>>>>
>>>> Any help on where to look for the error and any remedy would be
>>>> appriciated.
>>>>
>>>
>>>
>>> Amos
>>>
>>>
>>
Received on Tue Oct 27 2009 - 02:54:58 MDT