5

I am trying to run tests in Jenkins for a Python package which uses PyQt4, and the tests create windows. Since I'm running the tests in Jenkins, I need to redirect the graphical output, so I'm using xvfb-run. Most of the time, this works, but a fraction of the time, the testing will randomly fail with:

/usr/bin/xvfb-run: line 171: kill: (27375) - No such process

If I re-run the tests, it works fine most of the time (so it's just a one-off problem).

Has anyone encountered this issue before? Do you have any ideas for workarounds to improve the stability of the testing?

astrofrog
  • 32,883
  • 32
  • 90
  • 131
  • 4
    I think that is the line in the `xvfb-run` script where it tries to detect if there is another instance running, so if the `-a` switch was given, can retry with a different server number. Try running with `-a` switch (or `--auto-servernum`) to see if that makes any difference. – Pedro Romano Oct 02 '12 at 18:36
  • As @PedroRomano suggests above, `xvfb-run -a` is indeed the way. Ignore all answers below. Naturally, the only sane solution is the buried comment with the miniature font size. *Welcome to StackOverflow.* – Cecil Curry Mar 26 '22 at 04:44

2 Answers2

2

It work through find the Xvfb process and kill it.

ps auwx | grep "Xvfb" | grep -v grep
kqqsysu
  • 29
  • 3
1

If your copy of xvfb-run is the same as mine, I can confirm I've seen this too.

In my case, the target process caused Xvfb to crash. This means that the wrapper script itself fails at line 171 when tearing down no longer running Xvfb. To work around it I wrapped kill $XVFBPID in a set +e/set -e block. It also helps if you specify --error-file= so that xvfb-run saves the asynchronous standard error output from Xvfb while your target process is running, so you can get the underlying cause fixed.

Work around:

# Kill Xvfb now that the command has exited.
# Ignore failure of kill since we want to be forgiving of Xvfb itself crashing
set +e
kill $XVFBPID
set -e
shuckc
  • 2,766
  • 1
  • 22
  • 17