Menu
▾
▴
Re: [Bacula-users] Doc updates on log rotation and signal handling (WAS: Re: [Bacula-devel] Bacula-dir problems with -HUP? (was Re: Backtrace Attached: bacula-dir lockups on FreeBSD))
|
From: Kern S. <ke...@si...> - 2006-10-03 15:08:39
|
On Tuesday 03 October 2006 16:20, Brian A. Seklecki wrote:
> Well, at the very least, this behavior should be mentioned in the
> Documentation as:
It would be helpful in the future, and even for me to understand this email,
if you would start by precisely defining "this behavior".
I have the feeling you are confusing Bacula file "logging" with system
logging, both of which Bacula does. In a previous email, I was referring to
Bacula file logging, (system logging takes care of itself), and I am now
somewhat unsure if what I wrote was correct or not. After more reflection
and looking at the code, it seems possible to me that once the output file is
removed out from under Bacula, all further writing to that file by Bacula
will ultimately be lost.
Your email came across with a sort of "indignant" tone. I suppose you didn't
mean it that way, but if you are proposing a change to the document, it would
be helpful to submit a patch.
>
> *) It is of great concern to SAs
> *) Not an expected behavior of POSIX / F/OSS software
>
> Page 54 of my non-devel doc PDF reads:
>
> "Log Rotation
> If you use the default 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 logrotate
> from the scripts/logrotate to /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."
>
> This is fine, however logrotate.d/ is Redhat's bundle of joy. We should
> load some notes for other platforms. The BSD*'s for example tend to use
> newsyslog(8) and newsyslog.conf(5). I've ported both newsyslog(8) and
> logrotate(8) to Solaris in the past, but I had to beg and bleed with the
> Redhat people to send me the CVS version. Do HP-UX and AIX do logging?
> >:}
>
> 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.
>
> 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.
>
> The FreeBSD port maintainer might want to add a newsyslog.conf(5)
> example to the bacula-server/files/pkg-message.in:
>
> $ grep bacu /etc/newsyslog.conf
>
> /var/log/bacula.log bacula:bacula 660 10 * $W6D20 J
>
> ..suggesting how one might enable log rotation using Bacula internal
> logging and syslog facilities:
>
> $ grep -i bacu /etc/syslog.conf
>
> local0.* /var/log/bacula-syslog.log
>
>
> 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):
>
>
http://www.freebsd.org/cgi/man.cgi?query=signal&apropos=0&sektion=0&manpath=FreeBSD+6.1-RELEASE&format=html
>
> - SIGHUP (normally reload config and restart jobs)
> - SIGINFO (normally print a status report to log/stdout)
> - SIGTERM (kill)
> - SIGUSR1 (developer 1)
> - SIGUSR2 (develoepr 2)
>
> ~BAS
>
> On Tue, 2006-09-19 at 20:33 +0200, Kern Sibbald wrote:
> > On Tuesday 19 September 2006 20:26, Bill Moran wrote:
> > > In response to Kern Sibbald <ke...@si...>:
> > >
> > > > On Tuesday 19 September 2006 17:53, Bill Moran wrote:
> > >
> > > [snip]
> > >
> > > > > This is new to me. And not intuitive IMHO. Most programs interpret
a
> > HUP
> > > > > to mean "restart gracefully". I got the impression that it would be
> > about
> > > > > the same as issuing "reload" from bconsole. Most daemons require a
HUP
> > > > > signal to tell them to close and reopen their log files. I seem to
> > > > > remember reading a HOWTO that suggested hupping the director after
> > > > > log rotation, but I can't find it now -- perhaps my memory is
flawed.
> > > >
> > > > Yes, you are right, I was confusing a SIGHUP with a SIGTERM.
> > > >
> > > > SIGHUPing Bacula is never a very good idea. Depending on what version
of
> > > > Bacula it is, it will most likely crash. If I am not mistaken, so far
> > there
> > > > are no reported crashes against version 1.38.11.
> > >
> > > Well, that still tells me what to do to make the the problem go away,
> > although
> > > you can consider this a report of lockup when sending the director a
HUP ;)
> > >
> > > [snip]
> > >
> > > > > Personally, I find the director's handling of HUP atypical by
comparison
> > > > > to other Unix daemons. From the docs, it's not clear whether the
> > > > > director requires a signal to tell it to start logging to a new
file,
> > > > > I'm assuming (since HUP is a bad idea) that it does not?
> > > >
> > > > If you are talking about cycling a Job report log file as defined in
the
> > > > Messages resource, then there is probably no need to SIGHUP Bacula as
it
> > > > opens and closes the log file on a Job by Job basis, if I am not
mistaken.
> > >
> > > 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.
> >
> > 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.
> >
> > >
> > > Job reports split between two log files is an annoyance, but not
terrible.
> > > Corruption of old log data would be worse.
> >
> > No data gets corrupted, but potentially some could be lost.
> >
> > >
> > > [snip]
> > >
> > > > Yes, even if I did mistake SIGHUP and SIGTERM, it is not a good idea
to
> > SIGHUP
> > > > Bacula.
> > >
> > > I've adjusted the newsyslog config. Thanks for the feedback, as always.
> > >
> > > --
> > > Bill Moran
> > > Collaborative Fusion Inc.
> > >
> > > ****************************************************************
> > > IMPORTANT: This message contains confidential information and is
> > > intended only for the individual named. If the reader of this
> > > message is not an intended recipient (or the individual
> > > responsible for the delivery of this message to an intended
> > > recipient), please be advised that any re-use, dissemination,
> > > distribution or copying of this message is prohibited. Please
> > > notify the sender immediately by e-mail if you have received
> > > this e-mail by mistake and delete this e-mail from your system.
> > > E-mail transmission cannot be guaranteed to be secure or
> > > error-free as information could be intercepted, corrupted, lost,
> > > destroyed, arrive late or incomplete, or contain viruses. The
> > > sender therefore does not accept liability for any errors or
> > > omissions in the contents of this message, which arise as a
> > > result of e-mail transmission.
> > > ****************************************************************
> > >
> >
> > -------------------------------------------------------------------------
> > 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
> > Bac...@li...
> > https://lists.sourceforge.net/lists/listinfo/bacula-users
> --
> Brian A. Seklecki <bse...@co...>
> Collaborative Fusion, Inc.
>
|