git.sur5r.net Git - bacula/docs/blob - docs/manuals/de/old/problems/kaboom.tex

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