unusual feature.
This chapter explains what you should do if one of the three {\bf Bacula}
-daemons (Director, File, Storage) crashes.
+daemons (Director, File, Storage) crashes. When we speak of crashing, we
+mean that the daemon terminates abnormally because of an error. There are
+many cases where Bacula detects errors (such as PIPE errors) and will fail
+a job. These are not considered crashes. In addition, under certain
+conditions, Bacula will detect a fatal in the configuration, such as
+lack of permission to read/write the working directory. In that case,
+Bacula will force itself to crash with a SEGFAULT. However, before
+crashing, Bacula will normally display a message indicating why.
+For more details, please read on.
+
\subsection*{Traceback}
\index[general]{Traceback }
\begin{enumerate}
\item You must have an installed copy of {\bf gdb} (the GNU debugger), and it
- must be on {\bf Bacula's} path.
+ must be on {\bf Bacula's} path. On some systems such as Solaris, {\bf
+ gdb} may be replaced by {\bf dbx}.
\item The Bacula installed script file {\bf btraceback} must be in the same
directory as the daemon which dies, and it must be marked as executable.
\item The script file {\bf btraceback.gdb} must have the correct path to it
specified in the {\bf btraceback} file.
\item You must have a {\bf mail} program which is on {\bf Bacula's} path.
- \end{enumerate}
+ By default, this {\bf mail} program is set to {\bf bsmtp}, so it must
+ be correctly configured.
+\end{enumerate}
If all the above conditions are met, the daemon that crashes will produce a
traceback report and email it to you. If the above conditions are not true,
\footnotesize
\begin{verbatim}
gdb -quiet -batch -x /home/kern/bacula/bin/btraceback.gdb \
- $1 $2 2>\&1 | mail -s "Bacula traceback" your-address@xxx.com
+ $1 $2 2>\&1 | bsmtp -s "Bacula traceback" your-address@xxx.com
\end{verbatim}
\normalsize
To "manually" test the traceback feature, you simply start {\bf Bacula} then
obtain the {\bf PID} of the main daemon thread (there are multiple threads).
+The output produced here will look different depending on what OS and what
+version of the kernel you are running.
Unfortunately, the output had to be split to fit on this page:
\footnotesize
nothing happened. If this is not the case, you will need to correct the
problem by modifying the {\bf btraceback} script.
-Typical problems might be that {\bf gdb} is not on the default path. Fix this
-by specifying the full path to it in the {\bf btraceback} file. Another common
-problem is that the {\bf mail} program doesn't work or is not on the default
-path. On some systems, it is preferable to use {\bf Mail} rather than {\bf
-mail}.
+Typical problems might be that {\bf gdb} or {\bf dbx} for Solaris is not on
+the default path. Fix this by specifying the full path to it in the {\bf
+btraceback} file. Another common problem is that you haven't modified the
+script so that the {\bf bsmtp} program has an appropriate smtp server or
+the proper syntax for your smtp server. If you use the {\bf mail} program
+and it is not on the default path, it will also fail. On some systems, it
+is preferable to use {\bf Mail} rather than {\bf mail}.
\subsection*{Getting A Traceback On Other Systems}
\index[general]{Getting A Traceback On Other Systems }
\addcontentsline{toc}{subsection}{Getting A Traceback On Other Systems}
It should be possible to produce a similar traceback on systems other than
-Linux, either using {\bf gdb} or some other debugger. Solaris with {\bf gdb}
+Linux, either using {\bf gdb} or some other debugger. Solaris with {\bf dbx}
loaded works quite fine. On other systems, you will need to modify the {\bf
btraceback} program to invoke the correct debugger, and possibly correct the
{\bf btraceback.gdb} script to have appropriate commands for your debugger. If
projects / bacula / docs / blobdiff