How to Create Systemd File Block for BuildBot


Buildbot is a Python based continuous system integration for automating software build, testing and release processes. In the article, a prerequisite is to install BuildBot on Ubuntu 16.04, we created a buildbot user and group, installed buildmaster in / home / buildbot / master and worker in / home / buildbot / worker, then manually started the new user process.

In this article, we will create the Systemd module files so that the server init system can manage BuildBot processes.


One Ubuntu 16.04 server with at least 1 GB of RAMconfigured with non-root sudo user and firewall by following the initial server setup guide on Ubuntu 16.04 with BuildBot installed and configured using the following guide:

  • How to install BuildBot on Ubuntu 16.04

Once you’ve met these requirements, you’re ready to proceed.

Step 1 – Stopping Running Services

First, if you are still logged in as the buildbot user from the previous article, type exit to return to the sudo user.

As a sudo user, we’ll make sure Buildmaster is stopped:

sudo buildbot stop /home/buildbot/master

Then we stop the worker:

sudo buildbot-worker stop /home/buildbot/worker

In each case, we get a message that ‘buildbot process 1234 is dead, showing the Process ID that was stopped) or buildmaster no running’, which indicates that the service has not been started.

Step 2 – Creating a Buildmaster Module File

Next, we will create and open a file called buildbot-master.service:

sudo nano /lib/systemd/system/buildbot-master.service

In section [Unit] we will add a description and require the network to be available before the service starts. In section [Service] we will indicate that the process is running as the user and the buildbot group we created, define the working directory, and also provide the command that should be used to start the wizard. Finally, in the section [Install], we will specify that it should start as a target multi-user at boot:


Description=BuildBot master service

ExecStart=/usr/local/bin/buildbot start 


After we’ve added the content, we’ll save and exit, then test our work.

sudo systemctl start buildbot-master

We will use the status command in Systemd to check that it is running:

sudo systemctl status buildbot-master

The output should contain Active: active (running) and the last line should look something like this:


May 13 05:20:36 BuildBot-Install systemd[1]: Started BuildBot master service.

Finally, we’ll enable buildmaster to run on boot:

sudo systemctl enable buildbot-master


Created symlink from /etc/systemd/system/ to /lib/systemd/system/buildbot-master.service.

Now that buildmaster is installed, we’ll add worked.

Step 3 – creating the worker module file

We will create and open a file called buildbot-worker.service, which will be executed as buildbot-master.service but with the values ​​required to start the worker. In section [Install] we will use the WantedBy key in buildbot-master.service, this worker will be launched after buildmaster.

sudo nano /lib/systemd/system/buildbot-worker.service


Description=BuildBot worker service

ExecStart=/usr/local/bin/buildbot-worker start 


We’ll save and exit, and then use the systemctl command to start the worker:

sudo systemctl start buildbot-worker

We’ll use the status command to check for a successful launch:

sudo systemctl status buildbot-worker

Again, as master, we should see Active: active (running) and the last line of output should look something like this:


. . .
May 08 21:54:46 BuildBot-Install systemd[1]: Started BuildBot worker service.

Finally, we let the worker start at boot:

sudo systemctl enable buildbot-worker.service


Created symlink from /etc/systemd/system/buildbot-master.service.wants/buildbot-worker.service to /lib/systemd/system/buildbot-worker.service.

The output above indicates that the worker is configured to start at boot, but you must reboot the server currently to confirm the startup.


In this article, we added the Systemd module files so that the server init system can manage the BuildBot processes, and we enabled the buildmaster and worker to start at boot.