Re: [squid-users] issue with start / stop scripts

2015-11-28 Thread Alex Samad 
Hi

its in the scripts
stop() {
echo -n $"Stopping $prog: "
$SQUID -k check -f $SQUID_CONF >> /var/log/squid/squid.out 2>&1
RETVAL=$?
if [ $RETVAL -eq 0 ] ; then


Any reason to check the config before stopping a running squid ??


On 29 November 2015 at 09:32, Eliezer Croitoru  wrote:
> A check on what?
> Basically to verify if squid is still running you need to verify that there
> are is not one squid instance running.
> The PID is kind of a hack to make sure squid is still there or not.
> In most cases you can cancel the timeout and check only for the PID.
> Also notice that there is a "rm -rf" there which was inherited from an old
> script that I got as a "gift" since my own script got lost in a server
> migration.
>
> You can run three checks in parallel:
> - the pid exists or not
> - the process exists or not(using "ps aux|grep squid")
> - check if the port in netstat is still in listening mode.
>
> Hope it helps,
> Eliezer
>
>
> On 29/11/2015 00:21, Alex Samad wrote:
>>
>> Hi
>>
>> yeah from the rpms. I found the variables to lengthen the timeout period.
>>
>> But I got in the strange situation where the pid file was still there
>> (shutdown took longer than the timeout). and the scripts still thought
>> it was running, so stop would fail as it does a check first. do we
>> need to do a check first on shutdown ??
>>
>> A
>
>
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] issue with start / stop scripts

2015-11-28 Thread Amos Jeffries 
On 29/11/2015 11:32 a.m., Eliezer Croitoru wrote:
> A check on what?
> Basically to verify if squid is still running you need to verify that
> there are is not one squid instance running.
> The PID is kind of a hack to make sure squid is still there or not.
> In most cases you can cancel the timeout and check only for the PID.
> Also notice that there is a "rm -rf" there which was inherited from an
> old script that I got as a "gift" since my own script got lost in a
> server migration.
> 
> You can run three checks in parallel:
> - the pid exists or not
> - the process exists or not(using "ps aux|grep squid")
> - check if the port in netstat is still in listening mode.
> 


Also, be aware the shutdown signal for squid is SIGHUP. If you need to
abort the internal timeout use a second SIGHUP.

So the shutdown process as seen/done by external scripts should be:

* scan squid.conf for unusual pidfile_path and shutdown_lifetime values
* if squid.pid exists; send SIGHUP to process indicated inside
* else locate running squid process and send SIGHUP
* wait desired timeout + a few seconds

* if process still exists; repeat SIGHUP
* wait a few seconds more

* if process still exists; send SIGKILL; repeat until closed
* if squid.pid still exists; rm squid.pid


Notice the two points where waiting "a few seconds more" is needed for
the signals to have effects. That is the time Squid *actually* takes to
shutdown.

The shutdown_lifetime is a grace period where normal proxying operations
are still taking place to try and finish client transactions off. It is
essentially the *minimum* time needed for Squid to shutdown. If you just
abruptly abort/SIGKILL right at the same point where squid should only
be starting to seriousy wind up its own internal actions it can lead
cache and FD problems.

HTH
Amos

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

Re: [squid-users] file descriptors leak

2015-11-28 Thread André Janna 

Citando Amos Jeffries :


So, the first place to look is not Squid I think. But why at least 6 of
those ACK packets did not make it back to the client. That needs
resolving first to esure that the TCP level is operating correctly.

Only then if the problem remains looking at Squid, the use of port 443
indicates it is the crypto process is possibly waiting for something and
not closing the port on a 0-byte read(2) operation.



I took another network trace this time both at Squid and Windows client ends.

cache.log:
2015/11/27 11:30:55.610 kid1| SECURITY ALERT: Host header forgery  
detected on local=177.43.198.106:443 remote=192.168.64.4:61802 FD 5465  
flags=33 (local IP does not match any domain IP)


--
network trace at Squid side

client connects
11:30:55.604870 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [S],  
seq 1701554341, win 8192, options [mss 1460,nop,wscale  
8,nop,nop,sackOK], length 0
11:30:55.604992 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags  
[S.], seq 3125704417, ack 1701554342, win 29200, options [mss  
1460,nop,nop,sackOK,nop,wscale 7], length 0
11:30:55.605766 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],  
ack 1, win 256, length 0


client sends SSL hello
11:30:55.606242 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags  
[P.], seq 1:198, ack 1, win 256, length 197
11:30:55.606306 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],  
ack 198, win 237, length 0


client OS sends TCP keep-alive packets
11:31:05.607191 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],  
seq 197:198, ack 1, win 256, length 1
11:31:05.607231 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],  
ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
11:31:15.608966 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],  
seq 197:198, ack 1, win 256, length 1
11:31:15.609005 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],  
ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
11:31:25.614527 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],  
seq 197:198, ack 1, win 256, length 1
11:31:25.614589 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],  
ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0


client sends FIN
11:31:29.384280 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags  
[F.], seq 198, ack 1, win 256, length 0
11:31:29.421787 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],  
ack 199, win 237, length 0


client OS sends TCP keep-alive packets
11:31:39.417426 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],  
seq 198:199, ack 1, win 256, length 1
11:31:39.417489 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],  
ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
11:31:49.425366 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],  
seq 198:199, ack 1, win 256, length 1
11:31:49.425443 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],  
ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
11:31:59.426153 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],  
seq 198:199, ack 1, win 256, length 1
11:31:59.426233 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],  
ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
 it continues this way until I powered off Windows client after  
three hours ...



--
network trace at Windows client side

client connects
11:30:34.894242 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [S],  
seq 1701554341, win 8192, options [mss 1460,nop,wscale  
8,nop,nop,sackOK], length 0
11:30:34.898234 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags  
[S.], seq 3125704417, ack 1701554342, win 29200, options [mss  
1460,nop,nop,sackOK,nop,wscale 7], length 0
11:30:34.898298 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],  
ack 1, win 256, length 0


client sends SSL hello
11:30:34.898712 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags  
[P.], seq 1:198, ack 1, win 256, length 197
11:30:34.899479 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],  
ack 198, win 237, length 0


client OS sends TCP keep-alive packets
11:30:44.899271 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],  
seq 197:198, ack 1, win 256, length 1
11:30:44.899986 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],  
ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
11:30:54.900495 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],  
seq 197:198, ack 1, win 256, length 1
11:30:54.901323 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],  
ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
11:31:04.905731 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],  
seq 197:198, ack 1, win 256, length 1
11:31:04.906560 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],  
ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0


client sends FIN
11:31:08.675299 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags  
[F.], seq 198, ack 1, win 256, length

Re: [squid-users] issue with start / stop scripts

2015-11-28 Thread Eliezer Croitoru 

A check on what?
Basically to verify if squid is still running you need to verify that 
there are is not one squid instance running.

The PID is kind of a hack to make sure squid is still there or not.
In most cases you can cancel the timeout and check only for the PID.
Also notice that there is a "rm -rf" there which was inherited from an 
old script that I got as a "gift" since my own script got lost in a 
server migration.


You can run three checks in parallel:
- the pid exists or not
- the process exists or not(using "ps aux|grep squid")
- check if the port in netstat is still in listening mode.

Hope it helps,
Eliezer

On 29/11/2015 00:21, Alex Samad wrote:

Hi

yeah from the rpms. I found the variables to lengthen the timeout period.

But I got in the strange situation where the pid file was still there
(shutdown took longer than the timeout). and the scripts still thought
it was running, so stop would fail as it does a check first. do we
need to do a check first on shutdown ??

A


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

Re: [squid-users] issue with start / stop scripts

2015-11-28 Thread Alex Samad 
Hi

yeah from the rpms. I found the variables to lengthen the timeout period.

But I got in the strange situation where the pid file was still there
(shutdown took longer than the timeout). and the scripts still thought
it was running, so stop would fail as it does a check first. do we
need to do a check first on shutdown ??

A

On 29 November 2015 at 09:14, Eliezer Croitoru  wrote:
> What script are you using?
> If it's from my RPMs I might be able to patch it and make sure it will work
> better.
>
> Eliezer
>
> On 27/11/2015 08:09, Alex Samad wrote:
>>
>> Hi
>>
>> I have a rather long list of blocked address in my squid config.
>> and the default start stop timeout values are a bit short for my setup.
>>
>> when i did stop it failed because the time to parse the config took to
>> long. any reason it needs to parse to shutdown ?
>>
>> that left the pid file behind, which causes stop to fail again as
>> squid -k check -f /etc/squid/squid.conf
>>
>> fails no running process
>>
>> Alex
>> ___
>> 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

Re: [squid-users] issue with start / stop scripts

2015-11-28 Thread Eliezer Croitoru 

What script are you using?
If it's from my RPMs I might be able to patch it and make sure it will 
work better.


Eliezer

On 27/11/2015 08:09, Alex Samad wrote:

Hi

I have a rather long list of blocked address in my squid config.
and the default start stop timeout values are a bit short for my setup.

when i did stop it failed because the time to parse the config took to
long. any reason it needs to parse to shutdown ?

that left the pid file behind, which causes stop to fail again as
squid -k check -f /etc/squid/squid.conf

fails no running process

Alex
___
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] Warning about "Invalid entries" in cache.log (rock-store)

2015-11-28 Thread Alex Rousskov 
On 11/25/2015 11:22 PM, Tom Tom wrote:


> I'm running Squid 3.5.11 (Linux, 64Bit) with 16 workers and 4
> cache_dir's (rock) configured.
> 
> The 4 rock-caches where newly builded a few days ago. In the meantime,
> during squid-startup, I receive warnings like this:
> ...
> ...
> 2015/11/26 00:07:41 kid17| WARNING: Ignoring malformed cache entry.
> 2015/11/26 00:07:41 kid17| WARNING: Ignoring malformed cache entry.
> 2015/11/26 00:07:41 kid17| WARNING: Ignoring malformed cache entry.
> 2015/11/26 00:07:41 kid17| WARNING: Ignoring malformed cache entry.
> 2015/11/26 00:07:41 kid17| WARNING: Ignoring malformed cache entry.
> 2015/11/26 00:07:42 kid17| Finished rebuilding storage from disk.
> 2015/11/26 00:07:42 kid17|   287 Entries scanned
> 2015/11/26 00:07:42 kid17|  1092 Invalid entries.
> 2015/11/26 00:07:42 kid17| 4 With invalid flags.
> 2015/11/26 00:07:42 kid17|158845 Objects loaded.
> 2015/11/26 00:07:42 kid17| 0 Objects expired.
> ...
> ...
> 
> 
> How critical are the "Invalid entries"? What's the reason for these?

Most invalid entries are the results of "normal" conflicts when multiple
workers are trying to store the same entry and/or dealing with aborted
transactions. Squid crashes and restarts may add quite a few of these,
for example.

Unfortunately, it is not possible to say whether your "invalid entries"
are critical -- there is not enough information in the above stats. A
good rule of thumb may be to ignore a _small_ portion of invalid entries.

If yo want to dig deeper, enable "47,2" (at least) debugging using
debug_options and look for "freeBadEntry" lines. They should contain the
reason(s) why Squid considers your entries invalid. There may be other
"invalid entry" causes, but IFAICT, all others should be accompanied by
level-1 WARNINGS and/or other error counters.


HTH,

Alex.

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

Re: [squid-users] centos 6 install

2015-11-28 Thread Eliezer Croitoru 

Hey Mike,

How many servers do you have there?
The RPMs unfortunately works for me on too many production servers so I 
find your situation a bit weird.
I will be more then happy to hear about the issues you were or still 
having with my RPMs.

If I will not hear about them I will not be able to fix them.

All The Bests,
Eliezer

On 27/11/2015 23:19, Mike wrote:

Alex, I've had issues with his RPMs as well (using CentOS 6.4, 6.5 and
6.6 with various squid versions from 3.4.x to latest 3.5.11) so I just
compile and now that I have it down, it works well. Of the 7 RPMs of his
I've tried over the past year or two, none has worked, always has
various errors, permission problems, and/or doesn't have all the compile
options CentOS and Scientific Linux wants.

Mike


On 11/26/2015 17:00 PM, Alex Samad wrote:

Hi

I am trying to upgrade from the centos squid to the squid one
  rpm -qa | grep squid
squid-3.1.23-9.el6.x86_64
rpm -Uvh squid-3.5.11-1.el6.x86_64.rpm


getting this error
error: unpacking of archive failed on file
/usr/share/squid/errors/zh-cn: cpio: rename failed - Is a directory


ls -l
drwxr-xr-x. 2 root root 4096 Sep 16 13:05 zh-cn
lrwxrwxrwx. 1 root root7 Nov 27 09:57 zh-cn;56578e40 -> zh-hans
lrwxrwxrwx. 1 root root7 Nov 27 09:58 zh-cn;56578e77 -> zh-hans

going to remove the directory and try re installing
___
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

[squid-users] squid irc channel help

2015-11-28 Thread Ahmad Alzaeem 
Guys any one to help me to access irc channel on squid ?

 

http://en.irc2go.com/webchat/?net=freenode
 &room=squid

 

not working

 

cheers

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