[Bacula-docs] Doc updates: Log rotation and Signal Handling (WAS: Bacula-dir problems with -HUP? (was Re: Backtrace Attached: bacula-dir lockups on FreeBSD))

[Brian A. S. <bse...@co...>]

On Tue, 2006-10-03 at 17:07 +0200, Kern Sibbald wrote:
> On Tuesday 03 October 2006 16:20, Brian A. Seklecki wrote:
> > Well, at the very least, this behavior should be mentioned in the

As promised some 3 Months later (Sorry, BSDCon and all that)..

Attached is a basic diff(1) that explains log rotation techniques to
that effect.

The problem organizationally is that one can get lost in details in the
"Getting Started" section; where as this much info about log rotation
technique (e.g., platform-specific notes) may belong elsewhere in the
doc.  

Also not sure, as a general policy, how you want to deal with platform
specific config examples.  It seems TeX only has one-level of
"subsection"; I guess I'm spoiled by DocBook with its <sect[0-9]>
hierological organization.

> > We explicitly should mention that the log file's descriptor is only open
> > when being written to.  No SIGHUP is needed to close and reopen it as a
> > new file after the existing one is renamed/compressed. 

Right, and that a SIGHUP to the bacula-dir will interrupt running jobs.
Noted here!

> > The race condition that exists here is no different than any other
> > system.  Also, I don't see any examples of creating local[0-9] syslog(3)
> > facilities.   Certainly an example  "Messages {}" stanza that transmits
> > to syslogd(8) is in order.  Using syslog(3) mitigates this whole
> > problem.

I get into this here.

I'm curious why the facility can't be controlled.  Work-around
documented.  

> > The FreeBSD port maintainer might want to add a newsyslog.conf(5)
> > example to the bacula-server/files/pkg-message.in:

Attached is a diff to pkg-message.in for Dan Langille.

However, without ports/sysutils/syslog-ng, it's kind of a moot point.

> > A table/chart in the User or Developer documentation that outlines how
> > common POSIX signals are handled would be very helpful as well.  At
> > least the common ones in signal(3):

I didn't have a chance to get into this, but I still think it's a great
idea to have.  Put in the manual right after the Job Status Code
reference table >:}

> That's what I meant.  Although I'm still a bit concerned.  What happens 
> if the log file is rotated while a job is in progress?  Will bacula attempt to 
> append to the end of (the now compressed) previously opened file descriptor?  
> Or will it reconnect to the new file with the correct filename.

Right, in this case, if the is open by bacula-dir and the file is moved
on the same file system, the descriptor / inode stay the same.  If the
file is moved off of the file system, a new inode is made.  

Messages written to the old file inode during the move operation are
lost.

However, if the file is compressed at rotation-time, all data being
appended by bacula-dir to that still-open() file after the start of the
gzip(1)/bzip(2) read() operation would go into a "black hole" and be
lost.  

The resulting compressed data is a new file, so ignore whatever I was
thinking when I wrote that.

The appended data during the read() by the compression utility is lost
is the point I'm trying to make.

The advantage of syslog(3) is that it can queue messages on SIGHUP.
Also, the way newsyslog(8) works, the file presently open is simply
renamed/moved to $!.0, SIGHUP is sent, all queued messages enter a newly
created file in place.  No messages are ever lost.

> > > No, that is what Windows probably does. On Unix/Linux systems, Bacula 
> > > continues writing to the old file and when Bacula releases the file, it is 
> > > deleted.  Thus you lose the last part of what Bacula is writing if you 
> > > delete it out from under Bacula.