[exim-dev] [Bug 486] Monthly datestamped log files

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: Ted Cooper
Data:  
Para: exim-dev
Assunto: [exim-dev] [Bug 486] Monthly datestamped log files
------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://bugs.exim.org/show_bug.cgi?id=486

Ted Cooper <eximX0902w@???> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |Exim 4.70
            Version|4.66                        |4.69





--- Comment #8 from Ted Cooper <eximX0902w@???> 2009-10-06 23:44:22 ---
(In reply to comment #7)
> I thought I had replied to this, but I can't find anything in my Sent folder...
>
> (In reply to comment #6)
> > So it does sorry. Got confused up the top with the expand.c only returning one
> > of the types rathar than both. Completely missed the 2 different types with
> > different length towards the end. Still, does the variable expansion section
> > need to be expanded to include the new %M type return? currently the
> > $tod_logfile variable returns the yyyymmdd version, perhaps
> > $tod_logfile_monthly should return yyyymm to match.
>
> There's no reason to add another variable when the existing one can be
> truncated. The definition of $tod_logfile already explicitly refers to yyyymmdd
> and %D, so no change is required.


It's been a while but I think I was after having a variable that matched the
logfile name. But I guess if you know you're writing to monthly log files you
can just truncate $tod_logfile.

> > >Log file name management is not something that should be in logrotated. It's
> > >flawed because it requires moving files that could be actively in use.
> > You can move/rename an open file without incident on most *nix.
>
> Yes, but exim will still be writing to last month's file until signalled.


No, exim checks that it's writing to the correct file before writing every log
line leaving only a small window to write message started before the roll over
to the old file before creating/writing to the new one. No signal needed. I
actually wrote this in my last message too.

> If full strftime is required (and no one has requested it) then a new
> configuration option would be required as "%D" already isn't forward-
> compatible with strftime, so adding "%M" makes no difference.


Exactly 1 person has requested this feature and there is an easy work around to
get the same effect with logrotated and a little scripting (I actually have
this setup with daily logs moved to an archive at the end of the day). With
strftime I was looking for a way to make this as useful as possible to
everyone. If we're adding features, it's always best to add a fully featured
one than a gimped one. In this case the backwards compatibility is an issue so
this may be the best answer if it is to be included.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email