Daemonized buildbot start

Question

I'm trying to compose the simplest possible docker buildbot master image that runs buildbot start in ENTRYPOINT/CMD Dockerfile instructions.
I've tried to use a lot of combinations of dumb-init, gosu and exec, but with no success.
The situation is as follows:

1. When I try to run deamonized buildroot with the command docker run -d -v $local/vol/bldbot/master:/var/lib/buildbot buildbot-master-test, the container starts successfully, but it is terminated abruptly. The log looks as follows:

   [timestamp] [-] Log opened.
   [timestamp] [-] twistd 16.0.0 (/usr/bin/python 2.7.12) starting up.
   [timestamp] [-] reactor class: twisted.internet.epollreactor.EPollReactor.
   [timestamp] [-] Starting BuildMaster -- buildbot.version: 0.9.2
   [timestamp] [-] Loading configuration from '/var/lib/buildbot/master.cfg'
   [timestamp] [-] Setting up database with URL 'sqlite:/state.sqlite'
   [timestamp] [-] setting database journal mode to 'wal'
   [timestamp] [-] doing housekeeping for master 1 c8aa8b0d5ca3:/var/lib/buildbot
   [timestamp] [-] adding 1 new changesources, removing 0
   [timestamp] [-] adding 1 new builders, removing 0
   [timestamp] [-] adding 2 new schedulers, removing 0
   [timestamp] [-] No web server configured on this master
   [timestamp] [-] adding 1 new workers, removing 0
   [timestamp] [-] PBServerFactory starting on 9989
   [timestamp] [-] Starting factory
   [timestamp] [-] BuildMaster is running

2. When I run the container in an interactive mode with the command docker run --rm -it -v $local/vol/bldbot/master:/var/lib/buildbot buildbot-master-test /bin/sh and next I run the command buildbot start all works like charm.

I've already studied the content of official buildbot master docker image, i.e. buildbot/buildbot-master. I see that authors decided to use the command exec twistd -ny $B/buildbot.tac in start_buildbot.sh, not their own buildbot start.

So the question is, how to compose the ENTRYPOINT/CMD instructions in the Dockerfile that runs simply buildbot start.

---

ADDENDUM 1

Dockerfile content

FROM        alpine:3.4

ENV BASE_DIR=/var/lib/buildbot SRC_DIR=/usr/src/buildbot
COPY start $SRC_DIR/
RUN \
    echo @testing http://nl.alpinelinux.org/alpine/edge/testing >> /etc/apk/repositories && \
    echo @community http://nl.alpinelinux.org/alpine/edge/community >> /etc/apk/repositories && \
    apk add --no-cache \
        python \
        py-pip \
        py-twisted \
        py-cffi \
        py-cryptography@community \
        py-service_identity@community \
        py-sqlalchemy@community \
        gosu@testing \
        dumb-init@community \
        py-jinja2 \
        tar \
        curl && \
# install pip dependencies
    pip install --upgrade pip setuptools && \
    pip install "buildbot" && \
    rm -r /root/.cache

WORKDIR $BASE_DIR

RUN \
    adduser -D -s /bin/sh bldbotmaster && \
    chown bldbotmaster:bldbotmaster .

VOLUME $BASE_DIR

CMD ["dumb-init", "/usr/src/buildbot/start","buildbot","master"]

---

ADDENDUM 2

start script content

#!/bin/sh
set -e
BASE_DIR=/var/lib/buildbot

if [[ "$1" = 'buildbot' && "$2" = 'master' ]]; then

    if [ -z "$(ls -A "$BASE_DIR/master.cfg" 2> /dev/null)" ]; then
        gosu bldbotmaster buildbot create-master -r $BASE_DIR
        gosu bldbotmaster cp $BASE_DIR/master.cfg.sample $BASE_DIR/master.cfg
    fi

    exec gosu bldbotmaster buildbot start $BASE_DIR
fi

exec "$@"

Answer 1

Buildbot bootstrap is based on Twisted's ".tac" files, which are expected to be started using twistd -y buildbot.tac. The buildbot start script is actually just a convenience wrapper around twistd. It actually just run twistd, and then watches for the logs to confirm buildbot successfully started. There is no value added beyond this log watching, so it is not strictly mandatory to start buildbot with buildbot start. You can just start it with twistd -y buildbot.tac.

As you pointed up the official docker image is starting buildbot with twistd -ny buildbot.tac If you look at the help of twistd, -y means the Twisted daemon will run a .tac file, and the -n means it won't daemonize. This is because docker is doing process watching by itself, and do not want its entrypoint to daemonize.

The buildbot start command also has a --nodaemon option, which really only is 'exec'ing to twistd -ny. So for your dockerfile, you can as well us twistd -ny or buildbot start --nodaemon, this will work the same.

Another Docker specific is that the buildbot.tac is different. It configured the twistd logs to output to stdout instead of outputing to twisted.log. This is because docker design expects logs to be in stdout so that you can configure any fancy cloud log forwarder independently from the application's tech.

Answer 2

I've studied the docker reference and buildbot manual again and have found one hints.
There is a remark with an ngnix example

Do not pass a service x start command to a detached container. For example, this command attempts to start the nginx service.

$ docker run -d -p 80:80 my_image service nginx start

This succeeds in starting the nginx service inside the container. However, it fails the detached container paradigm in that, the root process (service nginx start) returns and the detached container stops as designed. As a result, the nginx service is started but could not be used. Instead, to start a process such as the nginx web server do the following:

$ docker run -d -p 80:80 my_image nginx -g 'daemon off;'

On the other hand there is an option

The --nodaemon option instructs Buildbot to skip daemonizing. The process will start in the foreground. It will only return to the command-line when it is stopped.

Both of the above trails yield

exec gosu bldbotmaster buildbot start --nodaemon $BASE_DIR

line in the start script's line that solves at least abrupt termination phenomenon.