提供されたxvfb-runスクリプトを使用してヘッドレステストを実行しようとする難しい問題を解決しています。wxya。 VirtualBoxで実行される独自のUbuntuイメージでは機能しますが、AtlassianがElastic Bamboo用に提供するUbuntu 15.04 AMIでは機能しません。ここまで問題を追跡しました。
xvfbの実行:
...
# 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)が生成されましたが、内容はありません。
根本原因について考えるか、それとも少なくとも深い研究?
答え1
ああ、気にしないでください。ついに問題を見つけました。 Atlassianは、シグナル転送を防ぐ独自のXvfbラッパースクリプト(/usr/local/bin/Xvfb)を追加しました。後でこの問題が発生する場合は、Xvfbが直接実行されるか、ラッパーを介して実行されていることを確認してください。これを行うと、xvfb-runが中断されます。
答え2
Atlassianラッパースクリプトなしで別の画像を使用しても同じ症状が発生する場合:
xvfb-runをコンテナの基本(init)プロセスとして使用すると、明らかに内部信号処理が中断され、wait
中断が発生します。 initプロセスを使用してこの問題を解決してください。非常に小さい、コンテナに追加するかdocker run --init
。