skip to Main Content

Is there any reason why xvfb-run will not be executed as docker overridden command?

Having an image from this Dockerfile:

FROM ubuntu:20.04

RUN apt-get update && apt-get install -y xvfb

Built with:

docker build -f Dockerfile.xvfb -t xvfb-test 

If I execute a custom docker command with xfvb-run:

docker run xvfb-test bash -x /usr/bin/xvfb-run echo

It gets stuck and never ends

But, if I enter to the image docker run --rm -it xvfb-test bash, and execute the same command xvfb-run echo it finished immediately (meaning that the Xvfb server started and was able to execute the command)

This is an excerpt of xvfb-run script:

...
trap : USR1
(trap '' USR1; exec Xvfb ":$SERVERNUM" $XVFBARGS $LISTENTCP -auth $AUTHFILE >>"$ERRORFILE" 2>&1) &
XVFBPID=$!

wait || :
...

Executing with bash -x we can see what lines is the last that was executed:

+ XAUTHORITY=/tmp/xvfb-run.YwmHlq/Xauthority
+ xauth source -
+ trap : USR1
+ XVFBPID=16
+ wait
+ trap '' USR1
+ exec Xvfb :99 -screen 0 1280x1024x24 -nolisten tcp -auth /tmp/xvfb-run.YwmHlq/Xauthority

2

Answers


  1. Chosen as BEST ANSWER

    Looking that the xvfb-run script and where it gets stucked seems that the signal USR1 (that Xvfb process sends) never gets propagated to the wait statement.

    A way to force signal propagation is to add the --init flag to docker run command. From the documentation, is exactly what it does.

    Run an init inside the container that forwards signals and reaps processes


  2. From this link

    The docker –init option in the run command basically sets ENTRYPOINT to tini and passes the CMD to it or whatever you specify on the commandline. Without init, CMD becomes pid 1. In this case, /bin/bash

    looks like running the command withouth init parameter, running as PID 1, is not handling the signal USR1 correctly.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search