Bind and Newsyslog under FreeBSD

Scott Bertilson scott at nts.umn.edu
Wed Dec 17 23:29:41 UTC 2003


> Scott Bertilson wrote:
> 
> >>In article <bra1a4$16sf$1 at sf1.isc.org> Walt Howard,
> >>You can reduce the problem by using a log-rollover program that is able
> >>to copy the existing logfile and then truncate it.  That way the named
> >>program can continue to use the same file descriptor, which it wants to
> >>    
> >>
> >
> >  I've seen this suggestion a few times and have always felt
> >like I must be missing something.  My understanding of
> >Unix/Linux file semantics would say that "named" would retain
> >the file offset to which it was writing so that this would
> >cause a "sparse" file to be created which would return NUL
> >bytes from the beginning of the file up to the file offset
> >after which you'd actually get the new log contents.  
> >
> This would only be true if "named" did an explicit seek() before each 
> write(). Why would it? If it simply opens the file in O_APPEND mode, 
> then after the truncate() it'll automatically start writing after the 
> *new* end-of-file.

  Duh!  Now that I hear it, that seems like the obviously
desirable interaction between O_APPEND and truncate().  It's
great to know.

> The bigger threat is that if "named" is using buffered I/O then a 
> truncate() of the file could cause the output which is committed to disk 
> to be broken in the middle of a line or output transaction, i.e. 
> corrupted. BIND appears to do an fflush() after every log write in order 
> to prevent this problem.

That and the possibility that something is written between
the time the copy finishes and the truncate executes.  It
seems to me that it would be better to either configure
named to rotate the log file or use syslog which will
cooperate well with rotation.

					Scott


More information about the bind-users mailing list