- Bacula Regression
- Kern Sibbald
- December 2003
+#
+# Copyright (C) 2000-2015 Kern Sibbald
+# License: BSD 2-Clause; see file LICENSE-FOSS
+#
+
+
+ Bacula Regression
+ Kern Sibbald
+
+This is Bacula's regression script directory.
+
+!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+Warning!!!! Make sure not to run it on the same system
+with your production Catalog because the tables will all
+be cleared. You can run it on the your production system
+if you use a different database. E.g. if your production
+system uses MySQL, you can use SQLite here.
+!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-This is Bacula's regression script directory. At this time
-(December 2003), it is still in development, so all the tests are
-not complete.
To set it up, create your personal configuration file, by
-copying prototype.conf to xxx.conf or simply editing prototype.conf
-directly.
+copying prototype.conf to config or simply editing prototype.conf
+directly then copying it to the file config.
-Then edit your conf file and define appropriate values
-for the variables that are in that file. If you want to see
-a real example, look at kern.conf, but please don't use my
-email address!
+You must end up with a file named config in the main regress
+directory that has all the specifications that correspond to
+your system.
-Make sure that depkgs is pre-built if it isn't
-already: (cd your-depkgs; make sqlite).
+If you are using SQLite, make sure that depkgs is pre-built if it
+isn't already: (cd your-depkgs; make sqlite).
+
+Note, if you use any database other than SQLite, be sure it is not
+your production database because Bacula will delete all the tables
+and recreate them. With SQLite, a new different database is created,
+so it will not affect your production system.
+
+Using the .conf file, you can now select between any Catalog type:
+SQLite, SQLite3, MySQL, or PostgreSQL. Be aware, however, if you
+use an installed database on a production server, running these
+tests will delete all the tables !!!!!!!!!!!!!!!!!! I run my
+tests on a non-production machine, and in addition, I normally use
+SQLite as the database, while my production uses MySQL.
Then do:
- ./config xxx.conf
make setup
You run the above one time. This will build a Makefile from
test. Aside from the required "make setup", each test is totally
self-initalizing and should clean up after itself.
-Not all the tests yet report OK. This is simply because there are
-some spurious differences that I haven't yet taken the time to
-eliminate. The working scrips as of 24 Apr 03 are:
+All the tests expect you to execute them from the main regress
+directory!
-backup-bacula-test
-sparse-test
-compressed-test
-sparse-compressed-test
-two-jobs-test
-wierd-files-test
-verify-vol-test
+Running the disk based tests:
-The tests expect you to execute them from the main regress
-directory!
+You can run all the disk based tests by doing:
+
+ ./do_file
+
+The disk based tests are totally separate from any production
+system, provided you have configured the database appropriately
+as noted above.
+
+Running all the "standard" tests:
+
+You can run all the disk and most of the tape tests by doing:
+
+ ./do_all
+
+======== Important !!! ============
+When running the tape tests, Bacula will write on any tape that
+is in the tape drive that you have configured. If it is a production
+Bacula tape, it will be destroyed. If you have configured an Autochanger,
+Bacula will write on the tapes in slots 1 and 2 thus destroying any
+information on those tapes, even if they are Bacula production tapes.
+===================================
+
+Each of the above calls one or more scripts. By looking at the
+scripts available in this directory, you can see that there are a number
+of options for running tests.
You can run them individually as:
this cleans up any files that may be created with root permissions.
+Tape test naming convention:
+
+The last part of the tape test name indicates (in general) what kind
+of test it is. They are broken (for the most part) into test names
+ending with:
+
+ -test => a disk based test
+ -tape => a tape based test (can be a standalone tape drive
+ or an autochanger). Only one tape will be used
+ and it is assumed to be mounted.
+ -changer => you have an autochanger
+
+Adding tests:
+
If you want to add more tests, do so by putting the shell script
in the tests subdirectory. Be careful when adding (or better not)
new clients, pools, and such to the test-bacula-dir.conf.in file
To avoid re-doing a make setup if you have made a change to the
conf files, and you do not need a new copy of the source, you can simply do:
- scripts/do-sed <your-email-address>
+ make sed
+
+Debugging failed tests:
+
+Prior versions required editing the tests/xxxx and changing a debug flag.
+However, that has been replaced by two environment variables:
+
+ REGRESS_DEBUG
+ REGRESS_WAIT
+
+If you define REGRESS_DEBUG, e.g.
+
+ REGRESS_DEBUG=1
+ export REGRESS_DEBUG
+
+then run a test, it will display the job and debug output.
+
+If you define REGRESS_WAIT, the script will stop and request:
+
+Start Bacula under debugger and enter anything when ready ...
+
+At this point, you can start any of the daemons under the debugger,
+then answer the message by entering any character. The script will
+then continue. For any daemon or daemons that you have manually started,
+you will see an error message when the script attempts to run a second
+copy, but those messages can be ignored. This makes it reasonably easy
+to run any component or components under the debugger if necessary.
+
+Explicit example:
+
+In shell window 1.
+
+cd regress
+export REGRESS_DEBUG=1
+export REGRESS_WAIT=1
+tests/name-of-script-test
+(wait until it tells you to start the debugger)
+
+In shell window 2
+
+cd regress/bin
+gdb bacula-xx (where xx is the component you want to debug).
+(possibly set a break point -- normally not)
+run -s -f
+(wait for the output to stop)
+
+In shell window 1
+(enter any character or simply a return)
+(ignore the error message it prints complaining that the daemon
+you are debugging is already running, which is in fact the case).
+
+
+That is all there is to it. The debugger window will get some
+output and will stop waiting for input if anything goes wrong
+like a seg fault. At that point, you can enter commands.
+
+The procedure avoids modifying the test scripts and trying to
+find pids and the such. If you want less debug output when
+debugging, don't set REGRESS_DEBUG=1.
+
+===
+
+Also, if you run from time to time on a computer that is not connected
+to the network, please be sure that "hostname" is set to "localhost",
+otherwise, your tests may fail because the hostname used by Bacula's
+./configure cannot be properly resolved.
+
+Anyway, you can debug where it is happening in the source code using the
+following example. For example, here I get the following backtrace:
+
+======= Backtrace: =========
+/lib/libc.so.6[0xb7b9d6e1]
+/lib/libc.so.6(cfree+0x89)[0xb7b9ed79]
+/home/kern/bacula/regress/bin/bacula-fd[0x8082ae5]
+/home/kern/bacula/regress/bin/bacula-fd[0x8082d58]
+/home/kern/bacula/regress/bin/bacula-fd[0x80838ac]
+/home/kern/bacula/regress/bin/bacula-fd[0x807aa3f]
+/home/kern/bacula/regress/bin/bacula-fd[0x807ac29]
+/home/kern/bacula/regress/bin/bacula-fd[0x804d188]
+/lib/libc.so.6(__libc_start_main+0xdc)[0xb7b4ef9c]
+/home/kern/bacula/regress/bin/bacula-fd[0x804cd21]
+
+Now to convert this into something more meaningful, kill off any hung Bacula
+processes. Note the one that was running -- above you see that it was
+bacula-fd, then bring the same binary up in the debugger. Then start at the
+first bacula-fd line, and feed the hex number to gdb as follows:
+
+info symbol 0x8082ae5
+free_addresses(dlist*) + 53 in section .text
+
+info symbol 0x8082d58
+add_address(dlist**, IPADDR::i_type, unsigned short, int, char const*, char
+const*, char**) + 568 in section .text
+
+Testing a Binary Installation:
+
+If you have installed your Bacula from a binary release such as (rpms or
+debs), you can still run regression tests on it. First, make sure that your
+regression config file uses the same catalog backend as your installed
+binaries. Then define the variables bin and scripts variables in your config
+file.
+
+Example:
+bin=/opt/bacula/bin
+scripts=/opt/bacula/scripts
+conf=/opt/bacula/etc
+
+The ./scripts/prepare-other-loc will tweak the regress scripts to use
+your binary location. You will need to run it manually once before you run any
+regression tests.
+
+$ scripts/prepare-other-loc
+$ tests/backup-bacula-test
+...
+
+All regression scripts must be run by hand or by calling the test scripts.
+These are principally scripts that begin with all_... such as all_disk_tests},
+./all_tests
+
+None of the
+./do_disk, ./do_all, ./nightly... scripts will work.
+
+If you want to switch back to running the regression scripts from source, first
+remove the bin, scripts, and conf variables from your config file and
+rerun the make setup step.
projects / bacula / bacula / blobdiff