git.sur5r.net Git - bacula/docs/blob - docs/manual/kaboom.tex

   1 %%
   2 %%
   3
   4 \section*{What To Do When Bacula Crashes (Kaboom)}
   5 \label{_ChapterStart47}
   6 \index[general]{Kaboom!What To Do When Bacula Crashes }
   7 \index[general]{What To Do When Bacula Crashes (Kaboom) }
   8 \addcontentsline{toc}{section}{What To Do When Bacula Crashes (Kaboom)}
   9
  10 If you are running on a Linux system, and you have a set of working
  11 configuration files, it is very unlikely that {\bf Bacula} will crash. As with
  12 all software, however, it is inevitable that someday, it may crash,
  13 particularly if you are running on another operating system or using a new or
  14 unusual feature.
  15
  16 This chapter explains what you should do if one of the three {\bf Bacula}
  17 daemons (Director, File, Storage) crashes.
  18
  19 \subsection*{Traceback}
  20 \index[general]{Traceback }
  21 \addcontentsline{toc}{subsection}{Traceback}
  22
  23 Each of the three Bacula daemons has a built-in exception handler which, in
  24 case of an error, will attempt to produce a traceback. If successful the
  25 traceback will be emailed to you.
  26
  27 For this to work, you need to ensure that a few things are setup correctly on
  28 your system:
  29
  30 \begin{enumerate}
  31 \item You must have an installed copy of {\bf gdb} (the GNU debugger),  and it
  32    must be on {\bf Bacula's} path.
  33 \item The Bacula installed script file {\bf btraceback} must  be in the same
  34    directory as the daemon which dies, and it must  be marked as executable.
  35 \item The script file {\bf btraceback.gdb} must  have the correct  path to it
  36    specified in the {\bf btraceback} file.
  37 \item You must have a {\bf mail} program which is on {\bf Bacula's}  path.
  38    \end{enumerate}
  39
  40 If all the above conditions are met, the daemon that crashes will produce a
  41 traceback report and email it to you. If the above conditions are not true,
  42 you can either run the debugger by hand as described below, or you may be able
  43 to correct the problems by editing the {\bf btraceback} file. I recommend not
  44 spending too much time on trying to get the traceback to work as it can be
  45 very difficult.
  46
  47 The changes that might be needed are to add a correct path to the {\bf gdb}
  48 program, correct the path to the {\bf btraceback.gdb} file, change the {\bf
  49 mail} program or its path, or change your email address. The key line in the
  50 {\bf btraceback} file is:
  51
  52 \footnotesize
  53 \begin{verbatim}
  54 gdb -quiet -batch -x /home/kern/bacula/bin/btraceback.gdb \
  55      $1 $2 2>\&1 | mail -s "Bacula traceback" your-address@xxx.com
  56 \end{verbatim}
  57 \normalsize
  58
  59 Since each daemon has the same traceback code, a single btraceback file is
  60 sufficient if you are running more than one daemon on a machine.
  61
  62 \subsection*{Testing The Traceback}
  63 \index[general]{Traceback!Testing The }
  64 \index[general]{Testing The Traceback }
  65 \addcontentsline{toc}{subsection}{Testing The Traceback}
  66
  67 To "manually" test the traceback feature, you simply start {\bf Bacula} then
  68 obtain the {\bf PID} of the main daemon thread (there are multiple threads).
  69 Unfortunately, the output had to be split to fit on this page:
  70
  71 \footnotesize
  72 \begin{verbatim}
  73 [kern@rufus kern]$ ps fax --columns 132 | grep bacula-dir
  74  2103 ?        S      0:00 /home/kern/bacula/k/src/dird/bacula-dir -c
  75                                        /home/kern/bacula/k/src/dird/dird.conf
  76  2104 ?        S      0:00  \_ /home/kern/bacula/k/src/dird/bacula-dir -c
  77                                        /home/kern/bacula/k/src/dird/dird.conf
  78  2106 ?        S      0:00      \_ /home/kern/bacula/k/src/dird/bacula-dir -c
  79                                        /home/kern/bacula/k/src/dird/dird.conf
  80  2105 ?        S      0:00      \_ /home/kern/bacula/k/src/dird/bacula-dir -c
  81                                        /home/kern/bacula/k/src/dird/dird.conf
  82 \end{verbatim}
  83 \normalsize
  84
  85 which in this case is 2103. Then while Bacula is running, you call the program
  86 giving it the path to the Bacula executable and the {\bf PID}. In this case,
  87 it is:
  88
  89 \footnotesize
  90 \begin{verbatim}
  91 ./btraceback /home/kern/bacula/k/src/dird 2103
  92 \end{verbatim}
  93 \normalsize
  94
  95 It should produce an email showing you the current state of the daemon (in
  96 this case the Director), and then exit leaving {\bf Bacula} running as if
  97 nothing happened. If this is not the case, you will need to correct the
  98 problem by modifying the {\bf btraceback} script.
  99
 100 Typical problems might be that {\bf gdb} is not on the default path. Fix this
 101 by specifying the full path to it in the {\bf btraceback} file. Another common
 102 problem is that the {\bf mail} program doesn't work or is not on the default
 103 path. On some systems, it is preferable to use {\bf Mail} rather than {\bf
 104 mail}.
 105
 106 \subsection*{Getting A Traceback On Other Systems}
 107 \index[general]{Getting A Traceback On Other Systems }
 108 \index[general]{Systems!Getting A Traceback On Other }
 109 \addcontentsline{toc}{subsection}{Getting A Traceback On Other Systems}
 110
 111 It should be possible to produce a similar traceback on systems other than
 112 Linux, either using {\bf gdb} or some other debugger. Solaris with {\bf gdb}
 113 loaded works quite fine. On other systems, you will need to modify the {\bf
 114 btraceback} program to invoke the correct debugger, and possibly correct the
 115 {\bf btraceback.gdb} script to have appropriate commands for your debugger. If
 116 anyone succeeds in making this work with another debugger, please send us a
 117 copy of what you modified.
 118 \label{ManuallyDebugging}
 119
 120 \subsection*{Manually Running Bacula Under The Debugger}
 121 \index[general]{Manually Running Bacula Under The Debugger }
 122 \index[general]{Debugger!Manually Running Bacula Under The }
 123 \addcontentsline{toc}{subsection}{Manually Running Bacula Under The Debugger}
 124
 125 If for some reason you cannot get the automatic traceback, or if you want to
 126 interactively examine the variable contents after a crash, you can run Bacula
 127 under the debugger. Assuming you want to run the Storage daemon under the
 128 debugger (the technique is the same for the other daemons, only the name
 129 changes), you would do the following:
 130
 131 \begin{enumerate}
 132 \item Start the Director and the File daemon. If the  Storage daemon also
 133    starts, you will need to find its PID  as shown above (ps fax | grep
 134    bacula-sd) and kill it  with a command like the following:
 135
 136 \footnotesize
 137 \begin{verbatim}
 138       kill -15 PID
 139
 140 \end{verbatim}
 141 \normalsize
 142
 143 where you replace {\bf PID} by the actual value.
 144 \item At this point, the Director and the File daemon should  be running but
 145    the Storage daemon should not.
 146 \item cd to the directory containing the Storage daemon
 147 \item Start the Storage daemon under the debugger:
 148
 149    \footnotesize
 150 \begin{verbatim}
 151     gdb ./bacula-sd
 152
 153 \end{verbatim}
 154 \normalsize
 155
 156 \item Run the Storage daemon:
 157
 158    \footnotesize
 159 \begin{verbatim}
 160      run -s -f -c ./bacula-sd.conf
 161
 162 \end{verbatim}
 163 \normalsize
 164
 165 You may replace the {\bf ./bacula-sd.conf} with the full path  to the Storage
 166 daemon's configuration file.
 167 \item At this point, Bacula will be fully operational.
 168 \item In another shell command window, start the Console program  and do what
 169    is necessary to cause Bacula to die.
 170 \item When Bacula crashes, the {\bf gdb} shell window will  become active and
 171    {\bf gdb} will show you the error that  occurred.
 172 \item To get a general traceback of all threads, issue the following  command:
 173
 174
 175 \footnotesize
 176 \begin{verbatim}
 177        thread apply all bt
 178
 179 \end{verbatim}
 180 \normalsize
 181
 182 After that you can issue any debugging command.
 183 \end{enumerate}
 184
 185 \subsection*{Getting Debug Output from Bacula}
 186 \index[general]{Getting Debug Output from Bacula }
 187 \addcontentsline{toc}{subsection}{Getting Debug Output from Bacula}
 188
 189 Each of the daemons normally has debug compiled into the program, but
 190 disabled. There are two ways to enable the debug output. One is to add the
 191 {\bf -d nnn} option on the command line when starting the debugger. The {\bf
 192 nnn} is the debug level, and generally anything between 50 and 200 is
 193 reasonable. The higher the number, the more output is produced. The output is
 194 written to standard output.
 195
 196 The second way of getting debug output is to dynamically turn it on using the
 197 Console using the {\bf setdebug} command. The full syntax of the command is:
 198
 199 \footnotesize
 200 \begin{verbatim}
 201  setdebug level=nnn client=client-name storage=storage-name dir
 202 \end{verbatim}
 203 \normalsize
 204
 205 If none of the options are given, the command will prompt you. You can
 206 selectively turn on/off debugging in any or all the daemons (i.e. it is not
 207 necessary to specify all the components of the above command).