I haven't checked the include files on my systems, but I'd assume there must
be some constant defined that holds the maximum file size limit - hopefully
this goes by the same name on most systems? Would it not be possible to
compute a running tab of the data written to any log file (and on startup
take the file size as the starting point) so that once it reaches near (I
say near because it's always better to be safe than sorry) the system limit,
it automatically rolls over to a new log file?
It could throw off 3rd party scripts/programs written to read in logfiles,
but it would be safer than having exim go nuts until it's fixed manually.
Just an idea thrown into the air!
Eli.
-----Original Message-----
From: exim-users-admin@??? [
mailto:exim-users-admin@exim.org] On Behalf
Of Gavin Sherry
Sent: Wednesday, January 21, 2004 6:47 PM
To: Andreas Metzler
Cc: exim-users@???
Subject: Re: [Exim] Exim 4.30 bug in handling large error files on Linux
On Wed, 21 Jan 2004, Andreas Metzler wrote:
> On Wed, Jan 21, 2004 at 09:44:18AM +1100, Gavin Sherry wrote:
> > I encountered a problem with Exim 4.30's handling of large error files
on
> > Linux. I had Exim generating verbose logging information and managed to
> > fill exim_mainlog to 2^31 bytes.
>
> > At this point write() fails since Exim doesn't appear to open the
mainlog
> > with O_LARGEFILE under Linux (a reasonable assumption). However, very
> > strange behaviour ensued.
> [...]
>
> One of the reasons we compile exim with "-D_FILE_OFFSET_BITS=64
> -D_LARGEFILE_SOURCE" on Debian. scnr.
Yes. It still doesn't address the problem itself; namely: unpredictable
behaviour at logging file offset boundaries. Naturally, you're going to
have a remarkably large log at the large file boundary but... :-)
Gavin
--
## List details at
http://www.exim.org/mailman/listinfo/exim-users Exim
details at
http://www.exim.org/ ##
