Bacula Developer Notes

This document is intended mostly for developers and describes how you can contribute to the Bacula project and the the general framework of making Bacula source changes.

Contributions

Contributions to the Bacula project come in many forms: ideas, participation in helping people on the bacula-users email list, packaging Bacula binaries for the community, helping improve the documentation, and submitting code.

Contributions in the form of submissions for inclusion in the project are broken into two groups. The first are contributions that are aids and not essential to Bacula. In general, these will be scripts or will go into the bacula/examples directory. For these kinds of non-essential contributions there is no obligation to do a copyright assignment as described below. However, a copyright assignment would still be appreciated.

The second class of contributions are those which will be integrated with Bacula and become an essential part (code, scripts, documentation, ...) Within this class of contributions, there are two hurdles to surmount. One is getting your patch accepted, and two is dealing with copyright issues. The following text describes some of the requirements for such code.

Patches

Subject to the copyright assignment described below, your patches should be sent in git format-patch format relative to the current contents of the master branch of the Source Forge git repository. Please attach the output file or files generated by the git format-patch to the email rather than include them directory to avoid wrapping of the lines in the patch. Please be sure to use the Bacula indenting standard (see below) for source code. If you have checked out the source with git, you can get a diff using.

git pull
git format-patch -M

If you plan on doing significant development work over a period of time, after having your first patch reviewed and approved, you will be eligible for having developer git write access so that you can commit your changes directly to the git repository. To do so, you will need a userid on Source Forge.

Copyrights

To avoid future problems concerning changing licensing or copyrights, all code contributions more than a hand full of lines must be in the Public Domain or have the copyright transferred to the Free Software Foundation Europe e.V. with a Fiduciary Licence Agreement (FLA) as the case for all the current code.

Prior to November 2004, all the code was copyrighted by Kern Sibbald and John Walker. After November 2004, the code was copyrighted by Kern Sibbald, then on the 15th of November 2006, Kern transferred the copyright to the Free Software Foundation Europe e.V. In signing the FLA and transferring the copyright, you retain the right to use the code you have submitted as you want, and you ensure that Bacula will always remain Free and Open Source.

Your name should be clearly indicated as the author of the code, and you must be extremely careful not to violate any copyrights or patents or use other people's code without acknowledging it. The purpose of this requirement is to avoid future copyright, patent, or intellectual property problems. Please read the LICENSE agreement in the main Bacula source code directory. When you sign the Fiduciary Licence Agreement (FLA) and send it in, you are agreeing to the terms of that LICENSE file.

If you don't understand what we mean by future problems, please examine the difficulties Mozilla was having finding previous contributors at www.mozilla.org/MPL/missing.html. The other important issue is to avoid copyright, patent, or intellectual property violations as was (May 2003) claimed by SCO against IBM.

Although the copyright will be held by the Free Software Foundation Europe e.V., each developer is expected to indicate that he wrote and/or modified a particular module (or file) and any other sources. The copyright assignment may seem a bit unusual, but in reality, it is not. Most large projects require this.

If you have any doubts about this, please don't hesitate to ask. The objective is to assure the long term survival of the Bacula project.

Items not needing a copyright assignment are: most small changes, enhancements, or bug fixes of 5-10 lines of code, which amount to less than 20% of any particular file.

Copyright Assignment - Fiduciary License Agreement

Since this is not a commercial enterprise, and we prefer to believe in everyone's good faith, previously developers could assign the copyright by explicitly acknowledging that they do so in their first submission. This was sufficient if the developer is independent, or an employee of a not-for-profit organization or a university. However, in an effort to ensure that the Bacula code is really clean, beginning in August 2006, all previous and future developers with SVN write access will be asked to submit a copyright assignment (or Fiduciary Licence Agreement - FLA), which means you agree to the LICENSE in the main source directory. It also means that you receive back the right to use the code that you have submitted.

Any developer who wants to contribute and is employed by a company should either list the employer as the owner of the code, or get explicit permission from him to sign the copyright assignment. This is because in many countries, all work that an employee does whether on company time or in the employee's free time is considered to be Intellectual Property of the company. Obtaining official approval or an FLA from the company will avoid misunderstandings between the employee, the company, and the Bacula project. A good number of companies have already followed this procedure.

The Fiduciary Licence Agreement is posted on the Bacula web site at: www.bacula.org/en/FLA-bacula.en.pdf

The instructions for filling out this agreement are also at: www.bacula.org/?page=fsfe

It should be filled out, then sent to:

     Kern Sibbald
     Cotes-de-Montmoiret 9
     1012 Lausanne
     Switzerland

Please note that the above address is different from the officially registered office mentioned in the document. When you send in such a complete document, please notify me: <kern at sibbald dot com>, and please add your email address to the FLA so that I can contact you to confirm reception of the signed FLA.

The Development Cycle

As discussed on the email lists, the number of contributions are increasing significantly. We expect this positive trend will continue. As a consequence, we have modified how we do development, and instead of making a list of all the features that we will implement in the next version, each developer signs up for one (maybe two) projects at a time, and when they are complete, and the code is stable, we will release a new version. The release cycle will probably be roughly six months.

The difference is that with a shorter release cycle and fewer released feature, we will have more time to review the new code that is being contributed, and will be able to devote more time to a smaller number of projects (some prior versions had too many new features for us to handle correctly).

Future release schedules will be much the same, and the number of new features will also be much the same providing that the contributions continue to come - and they show no signs of let up :-)

Feature Requests

In addition, we have “formalizee” the feature requests a bit.

Instead of me maintaining an informal list of everything I run into (kernstodo), we now maintain a “formal” list of projects. This means that all new feature requests, including those recently discussed on the email lists, must be formally submitted and approved.

Formal submission of feature requests will take two forms:

1. non-mandatory, but highly recommended is to discuss proposed new features on the mailing list.
2. Formal submission of an Feature Request in a special format. We'll give an example of this below, but you can also find it on the web site under Support → Feature Requests. Since it takes a bit of time to properly fill out a Feature Request form, you probably should check on the email list first.

Once the Feature Request is received by the keeper of the projects list, it will be sent to the Bacula project manager (Kern), and he will either accept it (90% of the time), send it back asking for clarification (10% of the time), send it to the email list asking for opinions, or reject it (very few cases).

If it is accepted, it will go in the projects file (a simple ASCII file) maintained in the main Bacula source directory.

Implementation of Feature Requests

Any qualified developer can sign up for a project. The project must have an entry in the projects file, and the developer's name will appear in the Status field.

How Feature Requests are accepted

Acceptance of Feature Requests depends on several things:

1. feedback from users. If it is negative, the Feature Request will probably not be accepted.
   
2. the difficulty of the project. A project that is so difficult that we cannot imagine finding someone to implement probably won't be accepted. Obviously if you know how to implement it, don't hesitate to put it in your Feature Request
3. whether or not the Feature Request fits within the current strategy of Bacula (for example an Feature Request that requests changing the tape to tar format probably would not be accepted, ...).

How Feature Requests are prioritized

Once an Feature Request is accepted, it needs to be implemented. If you can find a developer for it, or one signs up for implementing it, then the Feature Request becomes top priority (at least for that developer).

Between releases of Bacula, we will generally solicit Feature Request input for the next version, and by way of this email, we suggest that you send discuss and send in your Feature Requests for the next release. Please verify that the Feature Request is not in the current list (attached to this email).

Once users have had several weeks to submit Feature Requests, the keeper of the projects list will organize them, and request users to vote on them. This will allow fixing prioritizing the Feature Requests. Having a priority is one thing, but getting it implement is another thing - we are hoping that the Bacula community will take more responsibility for assuring the implementation of accepted Feature Requests.

Feature Request format:

============= Empty Feature Request form ===========
Item n:   One line summary ...
  Date:   Date submitted
  Origin: Name and email of originator.
  Status:

  What:   More detailed explanation ...

  Why:    Why it is important ...

  Notes:  Additional notes or features (omit if not used)
============== End Feature Request form ==============

============= Example Completed  Feature Request form ===========
Item 1:   Implement a Migration job type that will move the job
          data from one device to another.
  Origin: Sponsored by Riege Sofware International GmbH. Contact:
          Daniel Holtkamp <holtkamp at riege dot com>
  Date:   28 October 2005
  Status: Partially coded in 1.37 -- much more to do. Assigned to
          Kern.

  What:   The ability to copy, move, or archive data that is on a
          device to another device is very important.

  Why:    An ISP might want to backup to disk, but after 30 days
          migrate the data to tape backup and delete it from
          disk.  Bacula should be able to handle this
          automatically.  It needs to know what was put where,
          and when, and what to migrate -- it is a bit like
          retention periods.  Doing so would allow space to be
          freed up for current backups while maintaining older
          data on tape drives.

  Notes:  Migration could be triggered by:
           Number of Jobs
           Number of Volumes
           Age of Jobs
           Highwater size (keep total size)
           Lowwater mark
=================================================

Bacula Code Submissions and Projects

Getting code implemented in Bacula works roughly as follows:

• Kern is the project manager, but prefers not to be a “gate keeper”. This means that the developers are expected to be self-motivated, and once they have experience submit directly to the git repositories. However, it is a good idea to have your patches reviewed prior to submitting, and it is a bad idea to submit monster patches because no one will be able to properly review them. See below for more details on this.

• There are growing numbers of contributions (very good).

• Some contributions come in the form of relatively small patches, which Kern reviews, integrates, documents, tests, and maintains.

• All Bacula developers take full responsibility for writing the code, posting as patches so that we can review it as time permits, integrating it at an appropriate time, responding to our requests for tweaking it (name changes, ...), document it in the code, document it in the manual (even though their mother tongue is not English), test it, develop and commit regression scripts, and answer in a timely fashion all bug reports - even occasionally accepting additional bugs :-)

  This is a sustainable way of going forward with Bacula, and the direction that the project will be taking more and more. For example, in the past, we have had some very dedicated programmers who did major projects. However, some of these programmers due to outside obligations (job responsibilities change of job, school duties, ...) could not continue to maintain the code. In those cases, the code suffers from lack of maintenance, sometimes we patch it, sometimes not. In the end, if the code is not maintained, the code gets dropped from the project (there are two such contributions that are heading in that direction). When ever possible, we would like to avoid this, and ensure a continuation of the code and a sharing of the development, debugging, documentation, and maintenance responsibilities.

Patches for Released Versions

If you fix a bug in a released version, you should, unless it is an absolutely trivial bug, create and release a patch file for the bug. The procedure is as follows:

Fix the bug in the released branch and in the develpment master branch.

Make a patch file for the branch and add the branch patch to the patches directory in both the branch and the trunk. The name should be 2.2.4-xxx.patch where xxx is unique, in this case it can be “restore”, e.g. 2.2.4-restore.patch. Add to the top of the file a brief description and instructions for applying it - see for example 2.2.4-poll-mount.patch. The best way to create the patch file is as follows:

  (edit) 2.2.4-restore.patch
  (input description)
  (end edit)

   git format-patch -M
   mv 0001-xxx 2.2.4-restore.patch

check to make sure no extra junk got put into the patch file (i.e. it should have the patch for that bug only).

If there is not a bug report on the problem, create one, then add the patch to the bug report.

Then upload it to the 2.2.x release of bacula-patches.

So, end the end, the patch file is:

• Attached to the bug report

• In Branch-2.2/bacula/patches/...

• In the trunk

• Loaded on Source Forge bacula-patches 2.2.x release. When you add it, click on the check box to send an Email so that all the users that are monitoring SF patches get notified.

Developing Bacula

Typically the simplest way to develop Bacula is to open one xterm window pointing to the source directory you wish to update; a second xterm window at the top source directory level, and a third xterm window at the bacula directory <top>/src/bacula. After making source changes in one of the directories, in the top source directory xterm, build the source, and start the daemons by entering:

make

and

./startit

then in the enter:

./console

or

./gnome-console

to start the Console program. Enter any commands for testing. For example: run kernsverify full.

Note, the instructions here to use ./startit are different from using a production system where the administrator starts Bacula by entering ./bacula start. This difference allows a development version of Bacula to be run on a computer at the same time that a production system is running. The ./startit script starts Bacula using a different set of configuration files, and thus permits avoiding conflicts with any production system.

To make additional source changes, exit from the Console program, and in the top source directory, stop the daemons by entering:

./stopit

then repeat the process.

Debugging

Probably the first thing to do is to turn on debug output.

A good place to start is with a debug level of 20 as in ./startit -d20. The startit command starts all the daemons with the same debug level. Alternatively, you can start the appropriate daemon with the debug level you want. If you really need more info, a debug level of 60 is not bad, and for just about everything a level of 200.

Using a Debugger

If you have a serious problem such as a segmentation fault, it can usually be found quickly using a good multiple thread debugger such as gdb. For example, suppose you get a segmentation violation in bacula-dir. You might use the following to find the problem:

<start the Storage and File daemons>

cd dird
gdb ./bacula-dir
run -f -s -c ./dird.conf

<it dies with a segmentation fault> where The -f option is specified on the run command to inhibit dird from going into the background. You may also want to add the -s option to the run command to disable signals which can potentially interfere with the debugging.

As an alternative to using the debugger, each Bacula daemon has a built in back trace feature when a serious error is encountered. It calls the debugger on itself, produces a back trace, and emails the report to the developer. For more details on this, please see the chapter in the main Bacula manual entitled “What To Do When Bacula Crashes (Kaboom)”.

Memory Leaks

Because Bacula runs routinely and unattended on client and server machines, it may run for a long time. As a consequence, from the very beginning, Bacula uses SmartAlloc to ensure that there are no memory leaks. To make detection of memory leaks effective, all Bacula code that dynamically allocates memory must have a way to release it. In general when the memory is no longer needed, it should be immediately released, but in some cases, the memory will be held during the entire time that Bacula is executing. In that case, there must be a routine that can be called at termination time that releases the memory. In this way, we will be able to detect memory leaks. Be sure to immediately correct any and all memory leaks that are printed at the termination of the daemons.

Special Files

Kern uses files named 1, 2, ... 9 with any extension as scratch files. Thus any files with these names are subject to being rudely deleted at any time.

When Implementing Incomplete Code

Please identify all incomplete code with a comment that contains

***FIXME***

where there are three asterisks (*) before and after the word FIXME (in capitals) and no intervening spaces. This is important as it allows new programmers to easily recognize where things are partially implemented.

Bacula Source File Structure

The distribution generally comes as a tar file of the form bacula.x.y.z.tar.gz where x, y, and z are the version, release, and update numbers respectively.

Once you detar this file, you will have a directory structure as follows:

|
Tar file:
|- depkgs
   |- mtx              (autochanger control program + tape drive info)
   |- sqlite           (SQLite database program)

Tar file:
|- depkgs-win32
   |- pthreads         (Native win32 pthreads library -- dll)
   |- zlib             (Native win32 zlib library)
   |- wx               (wxWidgets source code)

Project bacula:
|- bacula              (main source directory containing configuration
   |                    and installation files)
   |- autoconf         (automatic configuration files, not normally used
   |                    by users)
   |- intl             (programs used to translate)
   |- platforms        (OS specific installation files)
      |- redhat        (Red Hat installation)
      |- solaris       (Sun installation)
      |- freebsd       (FreeBSD installation)
      |- irix          (Irix installation -- not tested)
      |- unknown       (Default if system not identified)
   |- po               (translations of source strings)
   |- src              (source directory; contains global header files)
      |- plugins       (plugins for FD/SD/DIR)
         |-fd          (FileDaemon plugins)
         |-sd          (Storage Daemon plugins)
         |-dir         (Director Daemon plugins)
      |- cats          (SQL catalog database interface directory)
      |- console       (bacula user agent directory)
      |- dird          (Director daemon)
      |- filed         (Unix File daemon)
      |- findlib       (Unix file find library for File daemon)
      |- lib           (General Bacula library)
      |- stored        (Storage daemon)
      |- tools         (Various tool programs)
      |- win32         (Native Win32 File daemon)
         |- libwin32   (Win32 files to make bacula-fd be a service)
         |- compat     (compatibility interface library)
         |- filed      (links to src/filed)
         |- findlib    (links to src/findlib)
         |- lib        (links to src/lib)
         |- console    (beginning of native console program)
         |- wx-console (wxWidget console Win32 specific parts)
         |- win32-installer (Makensis installer for 32bit)
         |- win64-installer (Makensis installer for 64bit)


Project regress:
|- regress             (Regression scripts)
   |- bin              (temporary directory to hold Bacula installed binaries)
   |- build            (temporary directory to hold Bacula source)
   |- scripts          (scripts and .conf files)
   |- tests            (test scripts)
   |- tmp              (temporary directory for temp files)
   |- working          (temporary working directory for Bacula daemons)

Project docs:
|- docs                (documentation directory)
   |- developers       (Developer's guide)
   |- home-page        (Bacula's home page source)
   |- manual           (html document directory)
   |- manual-fr        (French translation)
   |- manual-de        (German translation)
   |- techlogs         (Technical development notes);

Project gui:
|- gui                 (Bacula GUI projects)
  |- bacula-web        (Bacula web php management code)
  |- bimagemgr         (Web application for burning CDROMs)

Header Files

Please carefully follow the scheme defined below as it permits in general only two header file includes per C file, and thus vastly simplifies programming. With a large complex project like Bacula, it isn't always easy to ensure that the right headers are invoked in the right order (there are a few kludges to make this happen - i.e. in a few include files because of the chicken and egg problem, certain references to typedefs had to be replaced with void).

Every file should include bacula.h. It pulls in just about everything, with very few exceptions. If you have system dependent ifdefing, please do it in baconfig.h. The version number and date are kept in version.h.

Each of the subdirectories (console, cats, dird, filed, findlib, lib, stored, ...) contains a single directory dependent include file generally the name of the directory, which should be included just after the include of bacula.h. This file (for example, for the dird directory, it is dird.h) contains either definitions of things generally needed in this directory, or it includes the appropriate header files. It always includes protos.h. See below.

Each subdirectory contains a header file named protos.h, which contains the prototypes for subroutines exported by files in that directory. protos.h is always included by the main directory dependent include file.

Programming Standards

For the most part, all code should be written in C unless there is a burning reason to use C++, and then only the simplest C++ constructs will be used. Note, Bacula is slowly evolving to use more and more C++.

Code should have some documentation - not a lot, but enough so that I can understand it. Look at the current code, and you will see that I document more than most, but am definitely not a fanatic.

We prefer simple linear code where possible. Gotos are strongly discouraged except for handling an error to either bail out or to retry some code, and such use of gotos can vastly simplify the program.

Remember this is a C program that is migrating to a tiny subset of C++, so be conservative in your use of C++ features.

Do Not Use

• STL - it is totally incomprehensible.

Avoid if Possible

• Using void * because this generally means that one must using casting, and in C++ casting is rather ugly. It is OK to use void * to pass structure address where the structure is not known to the routines accepting the packet (typically callback routines). However, declaring void *buf is a bad idea. Please use the correct types whenever possible.

• Using undefined storage specifications such as (short, int, long, long long, size_t ...). The problem with all these is that the number of bytes they allocate depends on the compiler and the system. Instead use Bacula's types (int8_t, uint8_t, int32_t, uint32_t, int64_t, and uint64_t). This guarantees that the variables are given exactly the size you want. Please try at all possible to avoid using size_t ssize_t and the such. They are very system dependent. However, some system routines may need them, so their use is often unavoidable.

• Returning a malloc'ed buffer from a subroutine - someone will forget to release it.

• Heap allocation (malloc) unless needed - it is expensive. Use POOL_MEM instead.

• Templates - they can create portability problems.

• Fancy or tricky C or C++ code, unless you give a good explanation of why you used it.

• Too much inheritance - it can complicate the code, and make reading it difficult (unless you are in love with colons)

Do Use Whenever Possible

• Locking and unlocking within a single subroutine.

• A single point of exit from all subroutines. A goto is perfectly OK to use to get out early, but only to a label named bail_out, and possibly an ok_out. See current code examples.

• malloc and free within a single subroutine.

• Comments and global explanations on what your code or algorithm does.

• When committing a fix for a bug, make the comment of the following form:

  Reason for bug fix or other message. Fixes bug #1234
  

  It is important to write the bug #1234 like that because our program that automatically pulls messages from the git repository to make the ChangeLog looks for that pattern. Obviously the 1234 should be replaced with the number of the bug you actually fixed.

  Providing the commit comment line has one of the following keywords (or phrases), it will be ignored:

    tweak
    typo
    cleanup
    bweb:
    regress:
    again
    .gitignore
    fix compilation
    technotes
    update version
    update technotes
    update kernstodo
    update projects
    update releasenotes
    update version
    update home
    update release
    update todo
    update notes
    update changelog
  

• Use the following keywords at the beginning of a git commit message

Indenting Standards

We find it very hard to read code indented 8 columns at a time. Even 4 at a time uses a lot of space, so we have adopted indenting 3 spaces at every level. Note, indention is the visual appearance of the source on the page, while tabbing is replacing a series of up to 8 spaces from a tab character.

The closest set of parameters for the Linux indent program that will produce reasonably indented code are:

-nbad -bap -bbo -nbc -br -brs -c36 -cd36 -ncdb -ce -ci3 -cli0
-cp36 -d0 -di1 -ndj -nfc1 -nfca -hnl -i3 -ip0 -l85 -lp -npcs
-nprs -npsl -saf -sai -saw -nsob -nss -nbc -ncs -nbfda

You can put the above in your .indent.pro file, and then just invoke indent on your file. However, be warned. This does not produce perfect indenting, and it will mess up C++ class statements pretty badly.

Braces are required in all if statements (missing in some very old code). To avoid generating too many lines, the first brace appears on the first line (e.g. of an if), and the closing brace is on a line by itself. E.g.

   if (abc) {
      some_code;
  }

Just follow the convention in the code. For example we I prefer non-indented cases.

switch (code) {
case 'A':
   do something
   break;
case 'B':
   again();
   break;
default:
   break;
}

Avoid using // style comments except for temporary code or turning off debug code. Standard C comments are preferred (this also keeps the code closer to C).

Attempt to keep all lines less than 85 characters long so that the whole line of code is readable at one time. This is not a rigid requirement.

Always put a brief description at the top of any new file created describing what it does and including your name and the date it was first written. Please don't forget any Copyrights and acknowledgments if it isn't 100% your code. Also, include the Bacula copyright notice that is in src/c.

In general you should have two includes at the top of the an include for the particular directory the code is in, for includes are needed, but this should be rare.

In general (except for self-contained packages), prototypes should all be put in protos.h in each directory.

Always put space around assignment and comparison operators.

   a = 1;
   if (b >= 2) {
     cleanup();
  }

but your can compress things in a for statement:

   for (i=0; i < del.num_ids; i++) {
    ...

Don't overuse the inline if (?:). A full if is preferred, except in a print statement, e.g.:

   if (ua->verbose && del.num_del != 0) {
      bsendmsg(ua, _("Pruned %d %s on Volume %s from catalog.\n"), del.num_del,
         del.num_del == 1 ? "Job" : "Jobs", mr->VolumeName);
  }

Leave a certain amount of debug code (Dmsg) in code you submit, so that future problems can be identified. This is particularly true for complicated code likely to break. However, try to keep the debug code to a minimum to avoid bloating the program and above all to keep the code readable.

Please keep the same style in all new code you develop. If you include code previously written, you have the option of leaving it with the old indenting or re-indenting it. If the old code is indented with 8 spaces, then please re-indent it to Bacula standards.

If you are using vim, simply set your tabstop to 8 and your shiftwidth to 3.

Naming Convention

A fairly big amount of functions and variable are using the “snake_case” format, although you may find some classes that use the “CamelFormat”.

We strongly recommend to stick to the “snake_case” format to ease the reading of the code flow. Switching from one to the other is difficult and requires extra brain power.

Functions associated with a concept or a module and be prefixed with the name of the concept. For example, all Bacula Virtual FileSystem (bvfs) functions are prefixed with bvfs_.

Function and variable names must be readable, in general it is a bad idea to use striped down version of a function or a variable. In general you will find the following variables, functions or label in the code:

• ret - int/bool return code for a function
• buf - buffer
• bail_out - cleanup label for a function
• ed1, ed2, ed3 - temporary buffer used to convert integers (50c long)
• len - length of a buffer
• src - source
• dest - destination
• argc - argument count
• argk - argument key (key=val)
• argv - argument value (key=val)
• ua - User Agent object
• bvfs - Bacula Virtual File System
• lmgr - Lock Manager
• DCR - Device Control Resource
• ctx - Context

Locks and Threads

Bacula has a builtin lock manager called lmgr. This lock manager is a wrapper for common pthread or mutex operation. The lock manager will overwrite the different POSIX thread functions via src/lockmgr.h.

It can detect deadlock situation during the run time. Found a deadlock !!!!

The lock manager can prevent deadlock and help developers to design with the mutex list (lib/mutex_list.h). If all mutex are acquired/released with some predefined order, deadlocks are not possible.

ERROR: V out of order lock=%p %s:%i dumping lock

The lock manager will also dump all the mutex map during a backtrace. It can be analyzed easily to find the incorrect lock path. In the following example, we can see that one thread (0x7f67abe5f700) has requested to lock the same lock (0x6a8b40) two times from two different location.

threadid=0x7f67abe5f700 max=4 current=1
   lock=0x6a8b40 state=Granted priority=0 jobq.c:476
   lock=0x6a8b40 state=Wanted  priority=0 jobq.c:324

Using the thread id, we can locate in the backtrace what the thread was doing

Thread 982 (Thread 0x7f67abe5f700 (LWP 6211)):
#0  0x00007f6d1d8684ed in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007f6d1d863dcb in _L_lock_883 () from /lib64/libpthread.so.0
#2  0x00007f6d1d863c98 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00007f6d1dcebdcb in lmgr_p (m=m@entry=0x6a8b40 <job_queue>) at lockmgr.c:105
#4  0x00007f6d1dced2ed in bthread_mutex_lock_p ("jobq.c", 324) at lockmgr.c:1026
#5  0x0000000000430d82 in jobq_remove (jcr=jcr@entry=0x7f6cfcb542c8) at jobq.c:324
#6  0x000000000042ec9e in cancel_job (ua=ua@entry=0x7f6be807a7f8, jcr=jcr@entry=0x7f6cfcb542c8,
                            wait=wait@entry=60, cancel=cancel@entry=true) at job.c:746
#7  0x000000000042f10a in allow_duplicate_job (jcr=jcr@entry=0x7f6cfc361838) at job.c:1155
#8  0x00000000004317e5 in reschedule_job (je=0x7f6cfcac48d8, jq=0x6a8b40, jcr=0x7f6cfc361838) at jobq.c:675
#9  jobq_server (arg=arg@entry=0x6a8b40 <job_queue>) at jobq.c:494
#10 0x00007f6d1dcece25 in lmgr_thread_launcher (x=0x7f6cfc369578) at lockmgr.c:1184
#11 0x00007f6d1d861dd5 in start_thread () from /lib64/libpthread.so.0
#12 0x00007f6d1c289ead in clone () from /lib64/libc.so.6

We can also have some information about the job 0x7f67abe5f700 looking the jcr dump list.

threadid=0x7f67abe5f700 JobId=936628 JobStatus=t jcr=0x7f6cfc361838
        name=XXX-SQL.2019-08-17_21.30.00_07
	use_count=1 killable=0
	JobType=B JobLevel=F
	sched_time=18-Aug-2019 03:13 start_time=18-Aug-2019 00:18
	end_time=18-Aug-2019 02:43 wait_time=01-Jan-1970 01:00
	db=0x7f69b0921e28 db_batch=0x7f6bb0033d38 batch_started=0
	wstore=0x7f6b246262e8 rstore=(nil) wjcr=(nil) client=0x7f6b240c5438
        reschedule_count=1 SD_msg_chan_started=0

BDB=0x7f69b0921e28 db_name=bacula db_user=bacula connected=true
	cmd="SELECT MediaId,VolumeName,VolJobs,...
	RWLOCK=0x7f69b0921e40 w_active=0 w_wait=0

The lock manager can also handle threads, by default on Linux, it is not safe to call pthread_kill on a non existing thread. On linux, pthread_t is a pointer to a struct. As detached threads are released automatically, trying to kill an old thread will raise a segmentation fault. With the lockmanager, the replacement of the pthread_kill will check if the thread is registered in the lock manager before to kill it.

The lock manager also implements a ring of events. This list can be displayed in the backtrace file. It can be used to analyze the life of a mutex for example. (the backtrace is a fixed picture at a given time).

Tabbing

Tabbing (inserting the tab character in place of spaces) is as normal on all Unix systems - a tab is converted space up to the next column multiple of 8. My editor converts strings of spaces to tabs automatically - this results in significant compression of the files. Thus, you can remove tabs by replacing them with spaces if you wish. Please don't confuse tabbing (use of tab characters) with indenting (visual alignment of the code).

Don'ts

Please don't use:

strcpy()
strcat()
strncpy()
strncat();
sprintf()
snprintf()

They are system dependent and un-safe. These should be replaced by the Bacula safe equivalents:

char *bstrncpy(char *dest, char *source, int dest_size);
char *bstrncat(char *dest, char *source, int dest_size);
int bsnprintf(char *buf, int32_t buf_len, const char *fmt, ...);
int bvsnprintf(char *str, int32_t size, const char  *format, va_list ap);

See src/lib/bsys.c for more details on these routines.

Don't use the %lld or the %q printf format editing types to edit 64 bit integers - they are not portable. Instead, use %s with edit_uint64(). For example:

   char buf[100];
   uint64_t num = something;
   char ed1[50];
   bsnprintf(buf, sizeof(buf), "Num=%s\n", edit_uint64(num, ed1));

Note

: %lld is now permitted in Bacula code - we have our own printf routines which handle it correctly. The edit_uint64() subroutine can still be used if you wish, but over time, most of that old style will be removed.

The edit buffer ed1 must be at least 27 bytes long to avoid overflow. See src/lib/edit.c for more details. If you look at the code, don't start screaming that I use lld. I actually use subtle trick taught to me by John Walker. The lld that appears in the editing routine is actually #define to a what is needed on your OS (usually “lld” or “q”) and is defined in autoconf/configure.in for each OS. C string concatenation causes the appropriate string to be concatenated to the “%”.

Also please don't use the STL or Templates or any complicated C++ code.

Message Classes

Currently, there are five classes of messages: Debug, Error, Job, Memory, and Queued.

Debug Messages

Debug messages are designed to be turned on at a specified debug level and are always sent to STDOUT. There are designed to only be used in the development debug process. They are coded as:

DmsgN(level, message, arg1, ...)

where the N is a number indicating how many arguments are to be substituted into the message (i.e. it is a count of the number arguments you have in your message - generally the number of percent signs (%)). level is the debug level at which you wish the message to be printed. message is the debug message to be printed, and arg1, ... are the arguments to be substituted. Since not all compilers support #defines with varargs, you must explicitly specify how many arguments you have.

When the debug message is printed, it will automatically be prefixed by the name of the daemon which is running, the filename where the Dmsg is, and the line number within the file.

Some actual examples are:

Dmsg2(20, "MD5len=%d MD5=%s\n", strlen(buf), buf);

Dmsg1(9, "Created client %s record\n", client->hdr.name);

Debug Tags

It is possible to use tags to organize debug messages. When using a tag, it is possible to hide/show an entire class of messages. The message tags are defined in lib/messages.c/h

...
#define    DT_SCHEDULER  (1<<23)                /* scheduler */
#define    DT_PROTOCOL   (1<<22)                /* protocol */
#define    DT_DEDUP      (1<<21)                /* BEEF deduplication */
#define    DT_DDE        (1<<20)                /* BEEF dedup engine */
#define    DT_SNAPSHOT   (1<<19)                /* Snapshot */
#define    DT_RECORD     (1<<18)                /* Record/block */
#define    DT_CLOUD      (1<<17)                /* cloud   */
#define    DT_ALL        (0x7FFF0000)           /* all (up to debug_level 65635, 15 flags available) */

/* setdebug tag=all,-plugin */
static struct debugtags debug_tags[] = {
...
 { NT_("scheduler"),   DT_SCHEDULER,_("Debug scheduler information")},
 { NT_("protocol"),    DT_PROTOCOL, _("Debug protocol information")},
 { NT_("snapshot"),    DT_SNAPSHOT, _("Debug snapshots")},
 { NT_("record"),      DT_RECORD,   _("Debug records")},
 { NT_("all"),         DT_ALL,      _("Debug all information")},
 { NULL,               0,   NULL}
};

In the code, the tag can be used like in the following example:

  Dmsg0(DT_CLOUD|50, "This is a message about cloud\n");

The message will be displayed if the cloud tag is set AND if the debug level is at least 50.

setdebug level=50 tags=cloud storage

Error Messages

Error messages are messages that are related to the daemon as a whole rather than a particular job. For example, an out of memory condition my generate an error message. They should be very rarely needed. In general, you should be using Job and Job Queued messages (Jmsg and Qmsg). They are coded as:

EmsgN(error-code, level, message, arg1, ...) As with debug messages, you must explicitly code the of arguments to be substituted in the message. Error-code indicates the severity or class of error, and it may be one of the following (See table (here):

There are other error message classes, but they are in a state of being redesigned or deprecated, so please do not use them. Some actual examples are:

Emsg1(M_ABORT, 0, "Cannot create message thread: %s\n",strerror(status));

Emsg3(M_WARNING, 0, "Connect to File daemon %s at %s:%d failed. Retrying...\n",
      client->hdr.name, client->address,client->port);

Emsg3(M_FATAL, 0, "bdird<filed: bad response from Filed to %s command:
      %d %s\n",  cmd, n, strerror(errno));

Job Messages

Job messages are messages that pertain to a particular job such as a file that could not be saved, or the number of files and bytes that were saved. They Are coded as:

Jmsg(jcr, M\_FATAL, 0, "Text of message");

A Jmsg with M_FATAL will fail the job. The Jmsg() takes varargs so can have any number of arguments for substituted in a printf like format. Output from the Jmsg() will go to the Job report.

If the Jmsg is followed with a number such as Jmsg1(...), the number indicates the number of arguments to be substituted (varargs is not standard for #defines), and what is more important is that the file and line number will be prefixed to the message. This permits a sort of debug from user's output.

Queued Job Messages

Queued Job messages are similar to Jmsg()s except that the message is Queued rather than immediately dispatched. This is necessary within the network subroutines and in the message editing routines. This is to prevent recursive loops, and to ensure that messages can be delivered even in the event of a network error.

Memory Messages

Memory messages are messages that are edited into a memory buffer. Generally they are used in low level routines such as the low level device file dev.c in the Storage daemon or in the low level Catalog routines. These routines do not generally have access to the Job Control Record and so they return error essages reformatted in a memory buffer. Mmsg() is the way to do this.

Bugs Database

We have a bugs database which is at: bugs.bacula.org, and as a developer you will need to respond to bugs, perhaps bugs in general if you have time, otherwise just bugs that correspond to code that you wrote.

If you need to answer bugs, please be sure to ask the Project Manager (currently Kern) to give you Developer access to the bugs database. This allows you to modify statuses and close bugs.

The first thing is if you want to take over a bug, rather than just make a note, you should assign the bug to yourself. This helps other developers know that you are the principal person to deal with the bug. You can do so by going into the bug and clicking on the Update Issue button. Then you simply go to the Assigned To box and select your name from the drop down box. To actually update it you must click on the Update Information button a bit further down on the screen, but if you have other things to do such as add a Note, you might wait before clicking on the Update Information button.

Generally, we set the Status field to either acknowledged, confirmed, or feedback when we first start working on the bug. Feedback is set when we expect that the user should give us more information.

Normally, once you are reasonably sure that the bug is fixed, and a patch is made and attached to the bug report, and/or in the SVN, you can close the bug. If you want the user to test the patch, then leave the bug open, otherwise close it and set Resolution to Fixed. We generally close bug reports rather quickly, even without confirmation, especially if we have run tests and can see that for us the problem is fixed. However, in doing so, it avoids misunderstandings if you leave a note while you are closing the bug that says something to the following effect: We are closing this bug because ... If for some reason, it does not fix your problem, please feel free to reopen it, or to open a new bug report describing the problem”.

We do not recommend that you attempt to edit any of the bug notes that have been submitted, nor to delete them or make them private. In fact, if someone accidentally makes a bug note private, you should ask the reason and if at all possible (with his agreement) make the bug note public.

If the user has not properly filled in most of the important fields (platorm, OS, Product Version, ...) please do not hesitate to politely ask him. Also, if the bug report is a request for a new feature, please politely send the user to the Feature Request menu item on www.bacula.org. The same applies to a support request (we answer only bugs), you might give the user a tip, but please politely refer him to the manual and the Getting Support page of www.bacula.org.