Re: [squid-users] [BUG] Squid 3.2.x drops connections on -k rotate

From: Luciano Ruete <luciano.ruete_at_gmail.com>
Date: Thu, 02 May 2013 12:37:36 -0300

On 04/30/2013 09:42 PM, Amos Jeffries wrote:
> On 1/05/2013 4:04 a.m., Luciano Ruete wrote:
>> Hi,
>>
>> We are using squid 3.2.9 (but I checked change log up to 3.2.11
>> before writing this mail).
>>
>> If a user behind proxy starts a long file download and in the
>> meantime we do a -k rotate, that download gets broken.
>>
>> I think this is a bug.
>
> If it is actually Squid breaking the download that would be a bug.
> However -k rotate does not do anything with active connections.
> It:
> * restarts helpers, gracefully so that all pending requests are still
> served. It MAY break connections which are midway through NTLM
> handshake setup, but that is a transitory issue and disappears
> immediately on client retry.
> * renames the log files and starts writing to the new main log(s).
> * dumps the cache index journal out to a new file (swap.state) and
> starts using the new clean journal from that point onwards.
>
> Apart from the swap.state generation all of this takes a few dozen
> milliseconds at most. I'm not sure how long the swap.state writing
> takes and how it overaps with the post-rotate resumption.
>
> So can you please check your cache.log and system messages log
> carefully to ensure that; a) Squid is not in fact crashing during the
> rotate - which would definitely cut all transactions and b) how long
> the rotation is taking in the active worker process - more than a few
> ms rotation pausing time by Squid would allow TCP and NAT state timers
> to run out and play havoc with random connections.
>

Hi,

I can confirm that squid is not crashing during rotate, and also the
rotation is taking "0.01 seconds (2874035.41 entries/sec)." and similar.

We are recording logs in a tmpfs (RAM mounted as disk) in order to free
disk IO, and this RAM disk is only 1GB in size, so we start to rotate
every 10 minutes with a cron job using -k rotate.

After this users start to complain that they can not download large
files, and with further test we reduce this to exec -k rotate and
instantly cut the user download.

Currently we are using a single worker (workers = 1) and a single
cache_dir.
Received on Thu May 02 2013 - 15:47:35 MDT

This archive was generated by hypermail 2.2.0 : Fri May 03 2013 - 12:00:13 MDT