2.8 Launching the daemons

Both the buildmaster and the buildslave run as daemon programs. To launch them, pass the working directory to the buildbot and buildslave commands, as appropriate:

     # start a master
     buildbot start BASEDIR
     # start a slave
     buildslave start SLAVE_BASEDIR

The BASEDIR is option and can be omitted if the current directory contains the buildbot configuration (the buildbot.tac file).

     buildbot start

This command will start the daemon and then return, so normally it will not produce any output. To verify that the programs are indeed running, look for a pair of files named twistd.log and twistd.pid that should be created in the working directory. twistd.pid contains the process ID of the newly-spawned daemon.

When the buildslave connects to the buildmaster, new directories will start appearing in its base directory. The buildmaster tells the slave to create a directory for each Builder which will be using that slave. All build operations are performed within these directories: CVS checkouts, compiles, and tests.

Once you get everything running, you will want to arrange for the buildbot daemons to be started at boot time. One way is to use cron, by putting them in a @reboot crontab entry¹:

     @reboot buildbot start BASEDIR

When you run crontab to set this up, remember to do it as the buildmaster or buildslave account! If you add this to your crontab when running as your regular account (or worse yet, root), then the daemon will run as the wrong user, quite possibly as one with more authority than you intended to provide.

It is important to remember that the environment provided to cron jobs and init scripts can be quite different that your normal runtime. There may be fewer environment variables specified, and the PATH may be shorter than usual. It is a good idea to test out this method of launching the buildslave by using a cron job with a time in the near future, with the same command, and then check twistd.log to make sure the slave actually started correctly. Common problems here are for /usr/local or ~/bin to not be on your PATH, or for PYTHONPATH to not be set correctly. Sometimes HOME is messed up too.

Some distributions may include conveniences to make starting buildbot at boot time easy. For instance, with the default buildbot package in Debian-based distributions, you may only need to modify /etc/default/buildbot (see also /etc/init.d/buildbot, which reads the configuration in /etc/default/buildbot).

Buildbot also comes with its own init scripts that provide support for controlling multi-slave and multi-master setups (mostly because they are based on the init script from the debian package). With a little modification these scripts can be used both on debian and rhel based distributions and may thus prove helpful to package maintainers who are working on buildbot (or those that haven't yet split buildbot into master and slave packages).

     # install as /etc/default|sysconfig/buildslave
     master/contrib/init-scripts/buildslave.default
     
     # install /etc/default|sysconfig/buildslave
     master/contrib/init-scripts/buildmaster.default
     
     # install as /etc/init.d/buildslave
     slave/contrib/init-scripts/buildslave.init.sh
     
     # install as /etc/init.d/buildmaster
     slave/contrib/init-scripts/buildmaster.init.sh
     
     # ... and tell sysvinit about them
     chkconfig buildmaster reset
     # ... or
     update-rc.d buildmaster defaults