Thanks Henrik.
-D_FILE_OFFSET_BITS=64 worked for me.
Thank you very much.
-----Original Message-----
From: Henrik Nordstrom <henrik_at_henriknordstrom.net>
To: juris.krumins_at_ctco.lv
Cc: squid-users_at_squid-cache.org
Subject: Re: [squid-users] 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
Received on Thu Aug 20 2009 - 13:11:45 MDT
This archive was generated by hypermail 2.2.0 : Fri Aug 21 2009 - 12:00:03 MDT