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.
--- files/pkg-message.in Sat Sep 9 16:17:39 2006
+++ /tmp/pkg-message.in Mon Dec 18 17:00:33 2006
@@ -21,4 +21,21 @@
and that the documentation can be optionally installed with the
client port (sysutils/bacula-client).
+To activate Bacula's respective components, adjust rc.conf(5):
+
+bacula_fd_enable="YES"
+bacula_sd_enable="YES"
+bacula_dir_enable="YES"
+
+If you chose to use bacula-dir default internal logging, you may wish to adjust
+newsyslog.conf(5):
+
+ # rotate every week on Saturday at 8 PM; bzip2(1) compress
+ /var/log/bacula.log bacula:bacula 660 7 * $W6D20 JC
+
+If you chose to use bacula-dir syslog(3) logging:
+
+ # rotate at midnight
+ /var/log/bacula.log bacula:bacula 660 7 * @T00 J
+
################################################################################
--- quickstart.tex Mon Dec 18 16:51:20 2006
+++ quickstart.tex-lava Mon Dec 18 16:50:23 2006
@@ -344,16 +344,77 @@
\ilink{Running Bacula Chapter}{_ChapterStart1} of this manual where
you will get detailed instructions on how to run Bacula.
-\subsection*{Log Rotation}
+\subsection*{Log Rotation: General}
\index[general]{Rotation!Log }
\index[general]{Log Rotation }
\addcontentsline{toc}{subsection}{Log Rotation}
+
If you use the default {\bf bacula-dir.conf} or some variation of it, you will
-note that it logs all the Bacula output to a file. To avoid that this file
-grows without limit, we recommend that you copy the file {\bf logrotate} from
-the {\bf scripts/logrotate} to {\bf /etc/logrotate.d/bacula}. This will cause
-the log file to be rotated once a month and kept for a maximum of 5 months.
-You may want to edit this file to change the default log rotation preferences.
+note that the Messages section is configured to log all the Bacula messages
+output to a file. To avoid that this file grows without limit, we recommend
+that you rotate the log on a periodic basis.
+
+\subsection*{Log Rotation: Redhat Users}
+Redhat FC/ES/AS users may copy the file {\bf logrotate} from the {\bf
+scripts/logrotate} to {\bf /etc/logrotate.d/bacula}. This will cause the log
+file to be rotated once a month and kept for a maximum of 5 months. You may
+want to edit this file to change the default log rotation preferences.
+
+\subsection*{Log Rotation: *BSD Users}
+FreeBSD/NetBSD/OpenBSD/DragonFlyBSD/PC-BSD users may add the following line
+to {\bf newsyslog.conf(5)} for use by {\bf newsyslog(8)} :
+
+\footnotesize
+\begin{verbatim}
+/var/log/bacula.log bacula:bacula 660 10 * $W6D20 J
+\end{verbatim}
+\normalsize
+
+Note: You do not need to provide a PID file for {\bf newsyslog(8)} to send a
+{\bf SIGHUP} signal to recycle the file handler. Sending a {\bf SIGHUP} signal
+will interrupt running jobs. Bacula does not maintain a persistent file
+handler. As an alternative, use {\bf syslogd(8)} and {\bf syslog(3)} to avoid
+a small race condition here.
+
+\footnotesize
+\begin{verbatim}
+Messages {
+# ...
+# append = "/var/log/bacula.log" = all, !skipped
+syslog = all, !skipped
+# ... }
+\end{verbatim}
+\normalsize
+
+Note: Because you cannot stipulate the {\bf syslog(3)} facility, you must use a
+{\bf syslog-ng(8)} program() filter in {\bf syslog-ng.conf(5)} to catch all
+messages from {\bf bacula-dir} to facility-priority pair daemon.* into a
+specific destination:
+
+\footnotesize
+\begin{verbatim}
+syslog-ng.conf:
+
+#....
+destination baculadirlog { file("/var/log/bacula-dir.log" \
+ template("$FULLDATE $TZ $HOST [$PROGRAM][$PID] [$FACILITY] [$LEVEL]
$MSG\n") ); };
+
+#....
+filter f_prog_baculadir { program("bacula-dir"); };
+
+# Catch all logs from bacula-dir
+log { source(src); filter(f_prog_baculadir); filter(f_daemon);
destination(baculadirlog); flags(final); };
+
+Example output:
+
+$ sudo tail -F /var/log/bacula-dir.log
+Password:
+2006 Dec 18 16:07:04 EST hostname [bacula-dir][] [daemon] [err] bacula-dir:
hostname-dir: Prior failed job found. Upgrading to Full.
+\end{verbatim}
+\normalsize
+
+For additional details, see the \ilink{Messages Resource}{_ChapterStart15}
+Chapter of this manual.
\subsection*{Log Watch}
\index[general]{Watch!Log}
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
