Juris Krumins wrote:
Thanks Henrik.
-D_FILE_OFFSET_BITS=64 worked for me.
Thank you very much.
Just for clarity on the solution:
Did you have to set that while rebuilding _clamav_?? or something else?
Amos
-----Original Message-----
From: Henrik Nordstrom <henrik@xxxxxxxxxxxxxxxxxxx>
To: juris.krumins@xxxxxxx
Cc: squid-users@xxxxxxxxxxxxxxx
Subject: Re: Failed download files larger that 2GB through
proxy with ICAP.
Date: Thu, 20 Aug 2009 13:41:53 +0200
tor 2009-08-20 klockan 11:59 +0300 skrev Juris Krumins:
Following your suggestion I've captured traffic betwen ICAP and Squid.
11:11:05.864532 IP 127.0.0.1.49824 > 127.0.0.1.1345: P
2157719238:2157723337(4099) ack 2156830511 win 28786 <nop,nop,timestamp
1727787390 1727787383>
Squid sends data to the ICAP server.
11:11:05.877022 IP 127.0.0.1.1345 > 127.0.0.1.49824: R
2156830511:2156830511(0) ack 2157723337 win 30720 <nop,nop,timestamp
1727787403 1727787387>
ICAP server aborts with a TCP Reset, abnormally terminating the
transaction.
3) ICAP server logs following
The child 13559 not exited normaly.signaled with signal:25
Signal 25 is SIGXFSZ and man 7 signal shows us that:
SIGXFSZ 25,25,31 Core File size limit exceeded (4.2BSD)
Heh, there you go ;-)
So theoretically ICAP process/subprocess have to create core file
(because of default action specified in standart).
But I can't find it unfortunatelly.
It does not need to dump core. Depends on many factors.
And is not needed either as it's very obvious what happened. You ran an
32-bit application trying to store more than 2G of data in a file
without being compiled with LFS support. 2GB = 2^(32-1) bytes and is the
limit on what the POSIX file I/O API can handle in 32-bit mode.
Fix: Recompile the ICAP server with LFS support (64-bit file I/O), or
move to a 64-bit OS if supported by CPU and forget all of these 32-bit
issues...
REgards
Henrik
--
Please be using
Current Stable Squid 2.7.STABLE6 or 3.0.STABLE18
Current Beta Squid 3.1.0.13
