Xvfb で提供されているxvfb-runスクリプトを使用してヘッドレステストを実行しようとすると、厄介な問題が発生します。 VirtualBoxで実行されている自分のUbuntuイメージでは機能しますが、AtlassianがElasticBambooに提供しているUbuntu15.04AMIでは機能しません。私はここまで問題を追跡しました:
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
...
スクリプトは「待機」になりますが、Xvfbから予期されたSIGUSR1を取得することはありません。 (SIGUSR1を手動で送信すると、スクリプトは正常に進行します)。私はすべてのパッケージを最新のものに更新しました-最高ですが、それでも愛はありません。他のUbuntuシステムで動作させることができるので、奇妙です。 xvfbエラーログ($ ERRORFILE)が作成されますが、何も含まれていません。
根本原因についての考え、または少なくとも深く掘り下げるために?
ああ、気にしないでください、私はついに問題を発見しました-Atlassianは、シグナル送信をブロックしていた独自のXvfbラッパースクリプト(/ usr/local/bin/Xvfb)を追加しました。将来この問題が発生する場合は、Xvfbが直接実行されているのか、ラッパーを介して実行されているのかを確認してください。ラッパーの場合は、xvfb-runが壊れます。
Atlassianのラッパースクリプトを使用せずに、他の画像で同じ症状が発生した場合:
コンテナのメイン(init)プロセスとしてxvfb-runを使用すると、明らかにその内部シグナル処理が中断され、wait
もハングします。 tini などのinitプロセスを使用して、コンテナーに追加するか、docker run --init
を使用して、これを解決します。