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)}
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
16 This chapter explains what you should do if one of the three {\bf Bacula}
17 daemons (Director, File, Storage) crashes. When we speak of crashing, we
18 mean that the daemon terminates abnormally because of an error. There are
19 many cases where Bacula detects errors (such as PIPE errors) and will fail
20 a job. These are not considered crashes. In addition, under certain
21 conditions, Bacula will detect a fatal in the configuration, such as
22 lack of permission to read/write the working directory. In that case,
23 Bacula will force itself to crash with a SEGFAULT. However, before
24 crashing, Bacula will normally display a message indicating why.
25 For more details, please read on.
28 \subsection*{Traceback}
29 \index[general]{Traceback }
30 \addcontentsline{toc}{subsection}{Traceback}
32 Each of the three Bacula daemons has a built-in exception handler which, in
33 case of an error, will attempt to produce a traceback. If successful the
34 traceback will be emailed to you.
36 For this to work, you need to ensure that a few things are setup correctly on
40 \item You must have an installed copy of {\bf gdb} (the GNU debugger), and it
41 must be on {\bf Bacula's} path. On some systems such as Solaris, {\bf
42 gdb} may be replaced by {\bf dbx}.
43 \item The Bacula installed script file {\bf btraceback} must be in the same
44 directory as the daemon which dies, and it must be marked as executable.
45 \item The script file {\bf btraceback.gdb} must have the correct path to it
46 specified in the {\bf btraceback} file.
47 \item You must have a {\bf mail} program which is on {\bf Bacula's} path.
48 By default, this {\bf mail} program is set to {\bf bsmtp}, so it must
49 be correctly configured.
52 If all the above conditions are met, the daemon that crashes will produce a
53 traceback report and email it to you. If the above conditions are not true,
54 you can either run the debugger by hand as described below, or you may be able
55 to correct the problems by editing the {\bf btraceback} file. I recommend not
56 spending too much time on trying to get the traceback to work as it can be
59 The changes that might be needed are to add a correct path to the {\bf gdb}
60 program, correct the path to the {\bf btraceback.gdb} file, change the {\bf
61 mail} program or its path, or change your email address. The key line in the
62 {\bf btraceback} file is:
66 gdb -quiet -batch -x /home/kern/bacula/bin/btraceback.gdb \
67 $1 $2 2>\&1 | bsmtp -s "Bacula traceback" your-address@xxx.com
71 Since each daemon has the same traceback code, a single btraceback file is
72 sufficient if you are running more than one daemon on a machine.
74 \subsection*{Testing The Traceback}
75 \index[general]{Traceback!Testing The }
76 \index[general]{Testing The Traceback }
77 \addcontentsline{toc}{subsection}{Testing The Traceback}
79 To "manually" test the traceback feature, you simply start {\bf Bacula} then
80 obtain the {\bf PID} of the main daemon thread (there are multiple threads).
81 The output produced here will look different depending on what OS and what
82 version of the kernel you are running.
83 Unfortunately, the output had to be split to fit on this page:
87 [kern@rufus kern]$ ps fax --columns 132 | grep bacula-dir
88 2103 ? S 0:00 /home/kern/bacula/k/src/dird/bacula-dir -c
89 /home/kern/bacula/k/src/dird/dird.conf
90 2104 ? S 0:00 \_ /home/kern/bacula/k/src/dird/bacula-dir -c
91 /home/kern/bacula/k/src/dird/dird.conf
92 2106 ? S 0:00 \_ /home/kern/bacula/k/src/dird/bacula-dir -c
93 /home/kern/bacula/k/src/dird/dird.conf
94 2105 ? S 0:00 \_ /home/kern/bacula/k/src/dird/bacula-dir -c
95 /home/kern/bacula/k/src/dird/dird.conf
99 which in this case is 2103. Then while Bacula is running, you call the program
100 giving it the path to the Bacula executable and the {\bf PID}. In this case,
105 ./btraceback /home/kern/bacula/k/src/dird 2103
109 It should produce an email showing you the current state of the daemon (in
110 this case the Director), and then exit leaving {\bf Bacula} running as if
111 nothing happened. If this is not the case, you will need to correct the
112 problem by modifying the {\bf btraceback} script.
114 Typical problems might be that {\bf gdb} or {\bf dbx} for Solaris is not on
115 the default path. Fix this by specifying the full path to it in the {\bf
116 btraceback} file. Another common problem is that you haven't modified the
117 script so that the {\bf bsmtp} program has an appropriate smtp server or
118 the proper syntax for your smtp server. If you use the {\bf mail} program
119 and it is not on the default path, it will also fail. On some systems, it
120 is preferable to use {\bf Mail} rather than {\bf mail}.
122 \subsection*{Getting A Traceback On Other Systems}
123 \index[general]{Getting A Traceback On Other Systems }
124 \index[general]{Systems!Getting A Traceback On Other }
125 \addcontentsline{toc}{subsection}{Getting A Traceback On Other Systems}
127 It should be possible to produce a similar traceback on systems other than
128 Linux, either using {\bf gdb} or some other debugger. Solaris with {\bf dbx}
129 loaded works quite fine. On other systems, you will need to modify the {\bf
130 btraceback} program to invoke the correct debugger, and possibly correct the
131 {\bf btraceback.gdb} script to have appropriate commands for your debugger. If
132 anyone succeeds in making this work with another debugger, please send us a
133 copy of what you modified.
134 \label{ManuallyDebugging}
136 \subsection*{Manually Running Bacula Under The Debugger}
137 \index[general]{Manually Running Bacula Under The Debugger }
138 \index[general]{Debugger!Manually Running Bacula Under The }
139 \addcontentsline{toc}{subsection}{Manually Running Bacula Under The Debugger}
141 If for some reason you cannot get the automatic traceback, or if you want to
142 interactively examine the variable contents after a crash, you can run Bacula
143 under the debugger. Assuming you want to run the Storage daemon under the
144 debugger (the technique is the same for the other daemons, only the name
145 changes), you would do the following:
148 \item Start the Director and the File daemon. If the Storage daemon also
149 starts, you will need to find its PID as shown above (ps fax | grep
150 bacula-sd) and kill it with a command like the following:
159 where you replace {\bf PID} by the actual value.
160 \item At this point, the Director and the File daemon should be running but
161 the Storage daemon should not.
162 \item cd to the directory containing the Storage daemon
163 \item Start the Storage daemon under the debugger:
172 \item Run the Storage daemon:
176 run -s -f -c ./bacula-sd.conf
181 You may replace the {\bf ./bacula-sd.conf} with the full path to the Storage
182 daemon's configuration file.
183 \item At this point, Bacula will be fully operational.
184 \item In another shell command window, start the Console program and do what
185 is necessary to cause Bacula to die.
186 \item When Bacula crashes, the {\bf gdb} shell window will become active and
187 {\bf gdb} will show you the error that occurred.
188 \item To get a general traceback of all threads, issue the following command:
198 After that you can issue any debugging command.
201 \subsection*{Getting Debug Output from Bacula}
202 \index[general]{Getting Debug Output from Bacula }
203 \addcontentsline{toc}{subsection}{Getting Debug Output from Bacula}
205 Each of the daemons normally has debug compiled into the program, but
206 disabled. There are two ways to enable the debug output. One is to add the
207 {\bf -d nnn} option on the command line when starting the debugger. The {\bf
208 nnn} is the debug level, and generally anything between 50 and 200 is
209 reasonable. The higher the number, the more output is produced. The output is
210 written to standard output.
212 The second way of getting debug output is to dynamically turn it on using the
213 Console using the {\bf setdebug} command. The full syntax of the command is:
217 setdebug level=nnn client=client-name storage=storage-name dir
221 If none of the options are given, the command will prompt you. You can
222 selectively turn on/off debugging in any or all the daemons (i.e. it is not
223 necessary to specify all the components of the above command).