systemd環境においてDisk付替え作業を行う際の注意点

こんにちは。明日はお休みを頂いているので、本日深夜に催されるサッカー日本代表を心おきなく応援できる森屋です。(も、もちろん、応援のための休みではありません)

サッカーを、複数人が同席するVR空間上で応援できる時代が、早く来てほしいと願ってます...！

さて、CentOS7を使う上で避けて通れないsystemdさんですが、この前悪い意味でとんでもないおせっかいをしてくれたので、同じ現象で困る方の助けになればと筆を取りました。

Disk付替え時に発揮されたおせっかい

仮想環境やクラウド環境では、「Diskを付け替える」というシーンがままあります。

LVMでパーティション管理していない環境等では、例えばApacheで提供されるWEBサーバのDisk容量を拡張したい場合に、

①旧Diskより容量の大きい新Diskを用意する
②旧Diskのマウントポイント(/var/www)を使うApacheを停止する
③旧Diskから新Diskにデータをコピーする
④旧Diskをアンマウントする
⑤新Diskを/var/wwwにマウントする
　(この時、再起動時も自動マウントするよう、fstabに新DiskのUUIDを設定)
⑥/var/wwwを使うApacheを起動する
⑦旧Diskのデバイスとしての認識を解除する
⑧旧Diskを削除する

という手順をとることがあります。

この手順でいう⑦、

echo 1 > /sys/class/scsi_device/0:0:1:0/device/delete

を実行した直後、それは起こりました。

CPU使用率が急上昇し、/var/log/messagesに以下のログが大量かつ継続的に出力されていました。

Jun 28 hh:mm:ss hostname systemd: Unmounting /var/www...
Jun 28 hh:mm:ss hostname umount: umount: /var/www: target is busy.
Jun 28 hh:mm:ss hostname umount: (In some cases useful info about processes that use
Jun 28 hh:mm:ss hostname umount: the device is found by lsof(8) or fuser(1))
Jun 28 hh:mm:ss hostname systemd: var-www.mount mount process exited, code=exited status=32
Jun 28 hh:mm:ss hostname systemd: Failed unmounting /var/www.
Jun 28 hh:mm:ss hostname systemd: Unit var-www.mount is bound to inactive unit dev-disk-by\"旧DiskのUUID".device. Stopping, too.

※systemdのバージョンのせいなのか、何パターンか確認してます

Jun 28 hh:mm:ss hostname umount: umount: /var/www: target is busy.
Jun 28 hh:mm:ss hostname umount: (In some cases useful info about processes that use
Jun 28 hh:mm:ss hostname umount: the device is found by lsof(8) or fuser(1))
Jun 28 hh:mm:ss hostname systemd: var-www.mount mount process exited, code=exited status=32
Jun 28 hh:mm:ss hostname systemd: Failed unmounting /var/www.

どうやら、systemdは/etc/fstabの内容を基に「マウントポイント.mount」というUnitを作成するらしく、その情報に齟齬があった場合(今回は認識が外れた)、そのマウントポイントをアンマウントする機能がある様です。

完了しないIOキューが蓄積されないようにするためでしょうか。

ともかく、新Diskでマウントしているポイントが勝手にアンマウントされてしまうので、場合によっては甚大な影響を及ぼす動きをしてしまうということです。

Apacheの例だと、プロセスが稼働している限り常にマウントポイントをビジー状態で維持してくれるため、すぐには影響が出ませんが、なんらかのタイミングでApache再起動を実施した際に、停止の際に瞬間的にフリーになったマウントポイントが、systemdによってアンマウントされてしまうことでしょう。

そして、起動時にファイルが存在しない旨のエラーメッセージが出力されることかと想像します。

対処・回避方法

対処方法は簡単です。

systemdの持つ「マウントポイント.mount」を更新させていればこの現象は起きません。

つまり、現象発生後に対処する場合は、

systemctl daemon-reload

というコマンドを実行することで、情報が更新され、アンマウント処理が止まります。

回避したい場合は、手順でいう⑦の際に、

systemctl daemon-reload
echo 1 > /sys/class/scsi_device/0:0:1:0/device/delete

という風に、認識を外す前にfstabの情報を読ませてあげることで、アンマウント処理が回避できます。

さいごに

この大いなるおせっかいは、かなり用心していれば気付けるかもしれませんが、多くの場合すぐに気付けるものではありません。

Apacheを例にすると常にビジー状態にしてくれるので、影響は出にくいです。umountのプロセスでCPU使用率が上がることからも気付けるかもしれません。

日次処理で一時的に用いる様な領域であれば即アンマウントされます。

気を付けたいのは、大体ビジー状態ではあるものの、マウントポイントをフリーにするタイミングがあるプロセスだった場合です。

何の脈絡もないタイミングで自動的にアンマウントされてしまうため、原因究明に時間がかかることでしょう。

systemdのこの機能を知っていると知らないとでは、対処のスピードに大きく差が出ます。頭の片隅に置いておきましょう！