2

I've been working a knotty problem trying to run headless tests using the xvfb-run script provided with Xvfb. It works on my own Ubuntu images running in VirtualBox, but on the Ubuntu 15.04 AMI that Atlassian provides for Elastic Bamboo it doesn't. I've traced the problem down to here:

xvfb-run:

...
# Start Xvfb.
MCOOKIE=$(mcookie)
tries=10
while [ $tries -gt 0 ]; do
    tries=$(( $tries - 1 ))
    XAUTHORITY=$AUTHFILE xauth source - << EOF >>"$ERRORFILE" 2>&1
add :$SERVERNUM $XAUTHPROTO $MCOOKIE
EOF
    # handle SIGUSR1 so Xvfb knows to send a signal when it's ready to accept
    # connections
    trap : USR1
    (trap '' USR1; exec Xvfb ":$SERVERNUM" $XVFBARGS $LISTENTCP -auth $AUTHFILE >>"$ERRORFILE" 2>&1) &
    XVFBPID=$!
    wait || :
    if kill -0 $XVFBPID 2>/dev/null; then
        break
    elif [ -n "$AUTONUM" ]; then
        # The display is in use so try another one (if '-a' was specified).
        SERVERNUM=$((SERVERNUM + 1))
        SERVERNUM=$(find_free_servernum)
        continue
    fi
    error "Xvfb failed to start" >&2
    XVFBPID=
    exit 1
done
...

The script gets to the "wait" but never gets the expected SIGUSR1 from Xvfb. (If I send a SIGUSR1 manually the script proceeds normally). I updated all the packages to latest-greatest but still no love, and it's weird because I can make it work on other Ubuntu systems. The xvfb error log ($ERRORFILE) gets created but has nothing at all in it.

Thoughts on root cause, or at least to delve deeper?

2

Ah, never mind, I finally found the problem - Atlassian had added a Xvfb wrapper script of their own (/usr/local/bin/Xvfb) that was blocking the signal send. For anyone who has this issue in the future, check and see if Xvfb is being executed directly or via a wrapper, and if it's a wrapper it will break xvfb-run.

|improve this answer|||||
0

For anyone else running into the same symptoms with other images, without Atlassian's wrapper script:

Using xvfb-run as main (init) process for a container apparently breaks its internal signal handling, also causing wait to hang. Solve that by using an init process such as tini, either by adding it to the container or by using docker run --init.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.