Bug#1095028: xvfb: Race condition in xvfb-run
On Sun, 02 Feb 2025 at 20:05:41 +0100, Ole Streicher wrote:
the build of the "giza" package currently fails in some environments
due to an issue with xvfb-run [1], which is used from debian/rules.
The problem is that the xvfb-run script only checks that Xvfb is
running (by signalling with signal 0), but not whether it is actually
active (and accepts X client calls):
wait || :
if kill -0 $XVFBPID 2>/dev/null; then
break
Note that xvfb-run does have logic that is intended to wait for Xvfb to be
ready: it sets SIGUSR1 to be handled (with a trivial handler), and then
the wait(1) builtin in the quoted section has (is meant to have?) two
terminating conditions:
1. the xvfb-run script receives SIGUSR1, terminating wait(1)
unsuccessfully, after which Xvfb should already have its listening
socket ready to receive requests, `kill -0 $XVFBPID` should still
succeed, and then whatever tests we are running should also succeed;
2. or the Xvfb process terminates early due to an error, after which
wait(1) exits successfully, but then `kill -0 $XVFBPID` fails
(and then xvfb-run also fails)
But perhaps that logic is wrong? This is not a straightforward thing to
do correctly in shell script, and perhaps using a Perl or C helper would
be more reliable.
Xserver(1) documents two ways to wait for the X server to be ready. One
is the SIGUSR1 mechanism used by xvfb-run. The other is to run it with
option `-displayfd FD`, which makes it choose and output a display
number on the given fd, similar to `dbus-daemon --print-address=FD` (see
also test/simple-xinit.c and libxkbcommon_1.7.0-2/test/xvfb-wrapper.c).
This is not compatible with `xvfb-run --server-num` because it doesn't
allow the caller to influence the display number to use, but perhaps
`xvfb-run -a` could use -displayfd?
smcv
Reply to: