xvfb-run broken on elastic bamboo Ubuntu AMIs

I'm running Xvfb on an Elastic Bamboo Ubuntu instance (AMI ami-bba0fede, Ubuntu 15.04), like explained in the docs.  It works if I just do the DISPLAY= and run Xvfb directly.

But I'd like to use the xvfb-run wrapper script (/usr/bin/xvfb-run, part of the Xvfb package) instead - it picks a free display, so you can run multiple tests on the same system without them conflicting. If you just hardcode a display number then you can only run one at a time.

This works on Ubuntu in my local virtualbox but hangs on the Atlassian-provided AMI (both run from EB and also if I pull it up manually).  It does work on a stock Canonical Ubunti AMI (ami-3ad5af50) so there has to be something specifically changed on the Elastic Bamboo instances that's breaking it.

This works:

export DISPLAY=:99
Xvfb :99 -ac
pybot --nostatusrc --variablefile variables/vars.py -e TBD -e broken -x xunit -d reports/ tests/
<test output here>

This works on virtualbox but hangs on an instance created from the EB AMI (both by Bamboo and also if I just manually start one off the same AMI):

xvfb-run --server-args="-screen 0 1024x768x24" -a -e xvfb.log pybot --nostatusrc --variablefile variables/vars.py -
e TBD -e broken -x xunit -d reports/ tests/

I added a set -x to the /usr/bin/xvfb-run script to see what up and it hangs within xvfb-run while it's trying to find a clear display, before it gets to my code.

+ XVFB_RUN_TMPDIR=/tmp/xvfb-run.DJcsEj
+ tempfile -n /tmp/xvfb-run.DJcsEj/Xauthority
+ AUTHFILE=/tmp/xvfb-run.DJcsEj/Xauthority
+ mcookie
+ MCOOKIE=e1587c6161fa85ccc22010271b252b73
+ tries=10
+ [ 10 -gt 0 ]
+ tries=9
+ XAUTHORITY=/tmp/xvfb-run.DJcsEj/Xauthority xauth source -
+ trap : USR1
+ XVFBPID=2861
+ wait
+ trap USR1
+ exec Xvfb :99 -screen 0 1024x768x24 -nolisten tcp -auth /tmp/xvfb-run.DJcsEj/Xauthority
<hangs forever>

This is before my test code, it's basically a loop in xvfb-run that runs and tries to find a free display - 

# Start Xvfb.
while [ $tries -gt 0 ]; do
    tries=$(( $tries - 1 ))
    XAUTHORITY=$AUTHFILE xauth source - << EOF >>"$ERRORFILE" 2>&1
    # 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) &
    wait || :
    if kill -0 $XVFBPID 2>/dev/null; then
    elif [ -n "$AUTONUM" ]; then
        # The display is in use so try another one (if '-a' was specified).
        SERVERNUM=$((SERVERNUM + 1))
    error "Xvfb failed to start" >&2
    exit 1

It hangs on that trap/exec line. My bash-fu isn't good enough to figure out why.  Nothing appears in any log including the xvfb-run log if I configure one. 

Is anyone else running xvfb-run successfully, or know what this issue might be?


Addition: I've learned that it's Xvfb behavior to send a SIGUSR1 back to the parent process if the child process disconnects, which is what the parent shell is wait-ing on.  But that signal's either not getting sent or not getting received.


Solution: (why the heck can't you post an answer to your own question here?)

I found the issue.  Atlassian adds a /usr/local/bin/Xvfb wrapper script that sets listen tcp.   having another shell in between Xvfb and xvfb-run blocks the SIGUSR1 send.  It also seems like a security hole to turn on tcp listen without you knowing, but eh.  If anyone else is trying to use xvfb-run, just deleting their wrapper script will do the trick.

2 answers

Don't have an answer for you, but I just want to let you know that in my experience, the images get updated without notice.  I've had my company's build service taken out by Atlasssian image updates multiple times.  I think if you can wait, file a support request.  Otherwise, it's on you to figure out and fix

Right, I have logged a support ticket and am also working on figuring and fixing - hence asking here. I wonder if it works for people that have built their own elastic bamboo instance from the instructions as opposed to using the stock one?

0 vote

Update for Any one else that runs into this, the Bug is being tracked here:

Suggest an answer

Log in or Join to answer
Community showcase
Renan Battaglin
Published May 18, 2017 in Bamboo

FAQ: How to Upgrade Bamboo Server

Bamboo 5.9 will no longer be supported after June 12, 2017. What does this mean? As part of our End of Life policy, Atlassian supports major versions for two years after the first major iteratio...

1,087 views 0 5
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot