Enterprise Worker Start & Debug Containers

Stop and Start the Worker Service #

The following section explains how to stop and start the worker service with Ubuntu as the host operating system.

With Ubuntu 16.04 #

The Travis CI Worker is installed as a systemd service. The following commands can be used to check the status and start/stop the service:

$ sudo systemctl status travis-worker

$ sudo systemctl start travis-worker

$ sudo systemctl stop travis-worker

With Ubuntu 14.04 #

The Travis CI Worker is installed as an upstart service. The following commands can be used to check the status of the service and to start or stop it.

$ sudo status travis-worker
travis-worker start/running, process 9622

$ sudo stop travis-worker
travis-worker stop/waiting

$ sudo start travis-worker
travis-worker start/running, process 16339

When the worker is stopped with sudo stop travis-worker, it is shut down with a KILL signal. This stops all currently running build jobs and will enqueue them when the worker starts again. If you’d like to wait until some or all jobs are being worked off successfully, you can issue a SIGINT instead. This, together with a sleep, ensures that either some or all active jobs can finish (depending on how long your queue is). After sleep is finished, the worker has to be shut down via sudo stop travis-worker.

Worker Stop and Start Service Example #

The travis-worker behaves differently based on the signals it receives. For instance, a SIGINT drains the queue, it gives travis-worker enough time to work off all jobs which are still in progress, but it doesn’t accept any new ones.

SIGKILL, on the other hand, shuts down travis-worker immediately and cancels all currently running jobs. If you start the worker again afterward, all previously enqueued, and running jobs are re-queued again, so they’ll be worked off as usual.

With Ubuntu 16.04 #

With Ubuntu 16.04 as the host operating system, travis-works runs inside a Docker container, so starting and stopping the worker now works via systemctl:

$ sudo systemctl start travis-worker

$ sudo systemctl stop travis-worker

$ sudo systemctl status travis-worker

To send a SIGINT signal, please run the following:

sudo docker kill -s SIGINT travis-worker

With Ubuntu 14.04 #

In this example, a sleep 60 is used to allow jobs to complete before the worker is stopped. The actual value depends on how long your current job queue is and how long it takes on average for a job to finish, so you may wish to adjust accordingly.

$ sudo status travis-worker
travis-worker start/running, process 5671
$ sudo kill -s INT 5671
$ sleep 60
$ sudo status travis-worker
travis-worker start/post-stop, process 9405
$ sudo stop travis-worker

Start the Worker Debug Containers #

In order to start a build container on a Travis CI Enterprise Worker host, you can do the following:

# start a container and grab the port
id=$(docker -H tcp://0.0.0.0:4243 run -d -p 22 travis:php /sbin/init)
port=$(docker -H tcp://0.0.0.0:4243 port $id 22 | sed 's/.*://')

# ssh into the container (the default password is travis)
ssh travis@localhost -p $port

# stop and remove the container
docker -H tcp://0.0.0.0:4243 kill $id
docker -H tcp://0.0.0.0:4243 rm $id

(If travis-worker runs on Ubuntu 16.04, -H tcp://0.0.0.0:4243 is not necessary anymore)

Contact Enterprise Support #

To get in touch with us, please write a message to enterprise@travis-ci.com. If possible, please include as much of the following as you can:

• Description of the problem - what are you observing?
• Which steps did you try already?
• A support bundle (see table below on how to obtain it)
• Log files from all workers (They can be found at /var/log/upstart/travis-worker.log - please include as many as you can retrieve).
• If a build failed or errored, a text file of the build log

Since the announcement in Q3 2020, the most up to date version of Travis CI Enterprise is 3.x line. There are not any new releases for version 2.2 and the support patches has been limited since March 2021 as well. For existing users of Travis CI 2.x we strongly recommend upgrading to the latest Travis CI Enterprise 3.x.

Have you made any customizations to your setup? While we may be able to see some information (such as hostname, IaaS provider, and license expiration), there are many other things we cannot see which could lead to something not working. Therefore, we would like to ask you to also answer the questions below in your support request (if applicable):

• How many machines are you using / what is your Kubernetes cluster setup?
• Do you use configuration management tools (Chef, Puppet)?
• Which other services do interface with Travis CI Enterprise?
• Which Version Control system (VCS) do you use together with Travis CI Enterprise (e.g. github.com, GitHub Enterprise, or BitBucket Cloud)?
• If you are using GitHub Enterprise, which version of it?

We are looking forward to helping!