“CircleCI agent received a kill signal midway through the job” と急に言われるようになった話(2/12追記)


ラクスルでサーバサイドエンジニアをやっている小林です。

追記(2019/02/12)

CircleCI のバグ(?)だったようで、すでに修正されてます。

また、原因を少し追ったので、追記しました。

結論

CircleCI の command 内で exit すると、エラーになるので、

true / false コマンドを使って回避しました。

 

本編

今日も元気に開発を行っていたら、CircleCI のテストが下記のようなエラーで

失敗するようなりました。

最初、メモリが足りなくて殺されたのかなと思い、Rebuild with SSH でコンテナに ssh して、

topps を見ていたのですが、どうやらメモリ不足というわけではなさそうでした。

また、過去にテストの通っていたブランチを Rebuild してもテストがコケるので、

CircleCI の挙動が何かしら変わったのかなと思い、.circleci/config.yml の設定を見直してみました。

すると、command 内で下記のようなことをしているコードがありました。

status=0
for file in $(
  circleci tests glob \
  "src/*/*Bundle/Tests/**/*Test.php" | \
  circleci tests split --split-by=timings
)
do
  php ./bin/phpunit -c app --log-junit $CIRCLE_TEST_REPORTS/phpunit/${file}.junit.xml ${file}
  if [ $? -ne 0 ]; then status=1; fi
done
exit $status

最後の exit が明らかに怪しいので、試しに消してみたところテストが通りました。

どうやら、exit すると circleci-agent も死ぬようになったのかなと推測されます。

というわけで、下記のように true / false コマンドを使うように修正しました。

status=true
for file in $(
  circleci tests glob \
  "src/*/*Bundle/Tests/**/*Test.php" | \
  circleci tests split --split-by=timings
)
do
  php ./bin/phpunit -c app --log-junit $CIRCLE_TEST_REPORTS/phpunit/${file}.junit.xml ${file}
  if [ $? -ne 0 ]; then status=false; fi
done
$status

変数にコマンドを代入すると、その変数を評価することで、コマンドを実行することができます。

2時間ほどハマったので、同じようにハマった方のお役に立てれば幸いです。

 

追記(2019/02/12)

CircleCI の挙動が何かしら変わった

のところを、もう少し深ぼってみました。

まず、再現条件をもう少し明確にするために、空のリポジトリに下記のような .circleci/config.yml を用意して CircleCI を走らせてみました。

version: 2
jobs:
  build:
    docker:
      - image: circleci/ruby:2.5.1

    steps:
      - checkout

      - run:
          command: exit 0

しかし、これではテストは失敗しませんでした。

問題の起きた .circleci/config.yml と見比べてみると、問題の起きたテストでは shell を変更していたので、下記のように .circleci/config.yml を修正してみました。

version: 2
jobs:
  build:
    docker:
      - image: circleci/ruby:2.5.1

    shell: /bin/bash --login

    steps:
      - checkout

      - run:
          command: exit 0

すると、前述のエラーと共にテストが失敗するようになりました。

shell を指定しない場合、 /bin/bash -eo pipefail で実行されているので、念の為、
/bin/bash -eo pipefail --login を設定してみましたが、やはりテストが失敗しました。

どうやら、/bin/bash --login を設定し、かつ exit するとダメなようです。

さて、--login オプションを指定すると、起動時に ~/.profile を、終了時に ~/.bash_logout を実行するようになります。

Man page of BASH#起動

そこで、Rebuild with SSH でログインして、~/.bash_logout の中身を見てみると、下記のようになっていました。

# ~/.bash_logout: executed by bash(1) when login shell exits.

# when leaving the console clear the screen to increase privacy

if [ "$SHLVL" = 1 ]; then
    [ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q
fi

試しに、/usr/bin/clear_console を手動で叩いてみたところ、無事(?)「”CircleCI agent received a kill signal midway through the job”」というエラーと共にテストが失敗しました。

どうやら、/bin/bash --login で exit すると、~/.bash_logout内の /usr/bin/clear_console が実行され、テストが失敗する、というシナリオのようです。

さらに、/usr/bin/clear_console の中で何をやっているのかを追ってみました。

https://github.com/linuxmint/bash/blob/master/debian/clear_console.c

コードを見たところ、/dev/tty/dev/tty0/dev/console 、stdinstdoutstderr の順番に、ioctl(fd, KBDKBTYPE, &arg) を実行し、キーボードの種類が取得できたものについて、コンソールをクリアするという処理を行っていました。

特に kill している風でもなかったので、また、Rebuild with SSH でコンテナにログインして、開いているデバイスファイルを順に確認することにしました。

screen コマンドをインストールし、順番にデバイスファイルに接続していきます。

すると、screen /dev/console を実行すると、「”CircleCI agent received a kill signal midway through the job”」とエラーになってしまいました。

どうやら、/dev/console を参照しようとすると、エラーになるようです。

と、ここまで調べたところで、CircleCI側で修正されたようで、/dev/consoleを参照しても、エラーにならなくなりました。

無事、修正されたということで、追加の調査はここまでになりました。