"bk new" Dockerfile RUN instruction fails with "could not start uniq_server"

Install
1

I’m trying to initialise and add files to a BitKeeper repository, using Dockerfile RUN instructions:

COPY src/ ${self_test}
RUN chown -R ${user}:${group} ${self_test}
USER ${user}
WORKDIR ${self_test}
RUN bk init
RUN bk -Ux new
RUN bk commit -y"Initial commit"

When I attempt to build the image, it fails to start the uniq_server:

Removing intermediate container 6c80d4aa63f2
Step 8 : WORKDIR ${self_test}
 ---> Running in a82dcc0d55a1
 ---> 0f45f5fc5ea0
Removing intermediate container a82dcc0d55a1
Step 9 : RUN bk init
 ---> Running in fa22dd987ff7
 ---> 651c4afd67c5
Removing intermediate container fa22dd987ff7
Step 10 : RUN bk -Ux new
 ---> Running in 1e41b76f784c
could not start uniq_server after 21 tries
The command '/bin/sh -c bk -Ux new' returned a non-zero code: 1

If I comment out the last two instructions, build the image and attempt the bk new inside the container, I’m presented with a slightly more verbose error:

broker@a40787d89d78:/repositories/self-test$ bk -Ux new
waiting for uniqdb lock...WARNING-waiting for lock /tmp/.uniq_keys_broker (pid 8 getpid 14 findpid 0 real a40787d89d78.uk host b0cf605c7757.uk local 0)
waiting for uniqdb lock...WARNING-waiting for lock /tmp/.uniq_keys_broker (pid 8 getpid 14 findpid 0 real a40787d89d78.uk host b0cf605c7757.uk local 0)
waiting for uniqdb lock...WARNING-waiting for lock /tmp/.uniq_keys_broker (pid 8 getpid 14 findpid 0 real a40787d89d78.uk host b0cf605c7757.uk local 0)
error starting uniq_server: ERROR-uniqdb lock timeout

Unfortunately, I don’t know enough about the internals of BitKeeper to understand what this means.

2

I think it’s something to do with the way Docker handles /tmp, I was able to execute this manually by mapping the host’s /tmp into the container or using Docker’s --tmpfs option.

3

Interesting.

Yes, when bk is creating revision history it needs to make sure that the metadata being created is unique. Otherwise, multiple parallel imports on the same machine could generate duplicate names for csets or file deltas. This information is saved in a file in the $HOME/.bk directory and we spawn a local short term daemon to accumulate this information for performance reasons. That daemon uses a file in /tmp as a lock during startup.

You can set a $BK_DOTBK var in the environment that points at the .bk directory that should be used for this process and it that case the startup lockfile will be moved to that location as well.

Other suggestions? We can probably detect a docker environment and do something different if needed.

Also if this /tmp is unique to this docker instance and the hostname visible to processes in docker is not unique then there is risk if data might be created at the same time under the same conditions.

4

Could it be that the daemon is failing to spawn?

I can’t why changing the directory would have any impact, the $HOME/.bk directory won’t exist, but the Docker user should have permissions on their own $HOME directory.

I believe the /tmp is unique, although just a directory not a tmpfs file-system.

Interestingly, I added the init, new, commit sequence to an entrypoint.sh which gets run when docker run is called, as opposed to at build time and that doesn’t seem to care that /tmp isn’t a tmpfs partition. Perhaps I’m barking up the wrong tree about /tmp