X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=regress%2FREADME;h=1f42d211c2a64a8335100ee344099f2fbd2fcbd5;hb=143a5d11e207d0e14e25593045640c26ddb5d34c;hp=fb6547d1561cefcc67a5c44d392a242eada64cbd;hpb=7f12b27408ab878d9dd8223aca910c413731301a;p=bacula%2Fbacula diff --git a/regress/README b/regress/README index fb6547d156..1f42d211c2 100644 --- a/regress/README +++ b/regress/README @@ -1,33 +1,49 @@ - Bacula Regression - Kern Sibbald - April 2003 + Bacula Regression + Kern Sibbald -This is Bacula's regression script directory. At this time -(May 2003), it is still in development, so all the tests are -not complete. +This is Bacula's regression script directory. -To set it up, first edit Makefile and set BACULA-SOURCE to point -to your source. +!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! +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. +!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -!!!!!!!!!! IMPORTANT !!!!!!!! -Second, edit the EMAIL address in the Makefile to be your -email address and not mine or I will get LOTS of unwanted -email! -Third, edit the DEPKGS path in the Makefile to point to the -depkgs directory. +To set it up, create your personal configuration file, by +copying prototype.conf to config or simply editing prototype.conf +directly then copying it to the file config. -Fourth, make sure that depkgs is pre-built if it isn't -already: (cd your-depkgs; make sqlite). +You must end up with a file named config in the main regress +directory that has all the specifications that correspond to +your system. + +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: make setup -You run the above one time. This will copy the Bacula -source, configure, build it, and configure all the scripts -and conf files. If you change your source, you will need -to redo this command. +You run the above one time. This will build a Makefile from +Makefile.in and your xxx.conf file, copy the Bacula source, +configure, build it, and configure all the Bacula scripts +and conf files. If you change your source, you will need to +redo this command. Then you can run any of the tests in the tests subdirectory. Each test whose name ends in -root requires you to be root for @@ -35,20 +51,36 @@ a resonable run. Each test is totally independent of any other 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: @@ -71,3 +103,153 @@ to do: 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 +as it may invalidate a good number of tests, which respond to +questions by answering with a number (i.e. the order of the selection +list is known). It might be better to add your own testb-bacula... +configuration 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: + + 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 + +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 and scripts variables from your config file and +rerun the make setup step. +