バックエンドエンジニア 兼 SRE のまのめです。
くらしのマーケットでは、デプロイの仕組みとして ansible を採用しており、テスト環境の構築でも同じ仕組みを利用しています。
テスト環境は対応する git のブランチ別に構築することができるようにしています。
この環境を社内では tako 環境 と呼んでおり、テスト環境を構築することを tako を焼く と呼んでいます。
今回は、その tako 環境で遭遇したエラーに関して、備忘録的な意味で書いていこうと思います。
なお、ちょっとした対応の失敗も含んだ内容なので、あしからず。
事の発端
ある日、tako を焼いたメンバーから「tako 焼きに失敗する」と言われました。
エラーを見てみると、
NameError: name 'temp_path' is not defined
と書かれていますが、 temp_path という変数を register している箇所は ansible-playbook の task にありません。
はて…ということで、調査開始です。
調査
まずはググる、ということで該当のエラーで検索したところ、GitHub issue 上で
Out of disk space condition gives error
と言われていました。(リンク)
ということで、ディスクスペースを調べたのですが、
$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 16G 52K 16G 1% /dev
tmpfs 16G 112K 16G 1% /dev/shm
/dev/xxx 99G 46G 53G 7% /
(一部名前など改変しています)
といったように、ディスクスペースには問題がありません。
次に、そもそもコケている ansible-playbook の task の内容を確認したところ、
- name: install latest version of epel repository
yum:
name: epel-release
state: latest
となっています。
試しにこのコマンドを実行してみようと思い、tako 環境に入って epel-release のインストールを試したら、以下のように出ました。
$ sudo yum install epel-release
Loaded plugins: priorities, update-motd, upgrade-helper
Cannot open logfile /var/log/yum.log
Could not create lock at /var/run/yum.pid: [Errno 30] Read-only file system: '/var/run/yum.pid'
Can't create lock file; exiting
ほう…どうやらなにかしらが原因で yum の pid ファイルが lock されてしまったようです。
lock の解除のため、メンバーに許可を取って EC2 インスタンスを再起動してみたところ、問題が発生し、原因もわかりました。
原因
再起動をかけたところ、インスタンスステータスのチェックが失敗し続け、ssh もできなくなりました。
もはや中身を見ることが叶わなくなったので、EC2 のコンソールから「システムログの取得」をしたところ、こんなエラーが出ていました。
[/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a /dev/xxx
/ contains a file system with errors, check forced.
/: Inodes that were part of a corrupted orphan linked list found.
/: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
[FAILED]
*** An error occurred during the file system check.
***/dev/fd/9: line 2: plymouth: command not found
Give root password for maintenance
＼(^o^)／
どうやら EBS の問題で、 ファイルシステムに不良が出てしまった ようです。
ファイルロックがかかっていたのも関係していそうですね。
対処
EBS の差し替え目的で、インスタンスを立て直しました。
tako 環境用にいろいろ設定するのが手間ですが、仕方ないです。
最後に
tako 環境は無事復旧できました。
パニックになっていたのでインスタンスの再起動という手を取りましたが、それまでは ssh できていたので、普通に fsck をやればもっと早く原因が分かって対処もできたはずですね。
あと、epel-release のインストールにコケた際に、もう少し詳細に調べたほうが良かったです。
そもそも lock ファイルが作れないというエラーなので、もうその時点でおかしいですよね。
私たちテックチームでは「くらしのマーケット」を一緒に作る仲間を募集しています。
今回のようなケースをスマートに解決できる SRE の方も大募集中です。
くらしのマーケットのシステムに興味がある方はコーポレートサイト https://www.minma.jp/ までお気軽にご連絡ください！
