sambaサーバのデータ用ディスクが故障してしまい交換したのですが、その後もう一つトラップが待っていて週末はそれにかかりきりとなってしまいました。その内容のご報告です。
sambaサーバ停止
監視用のアラートがsambaサーバの動作停止を示すアラートを報告していました。しかしユーザがいない時間帯だったため夜間バックアップ以外の影響はなし。
翌日に機器を直接確認してみることにしました。
サーバ画面でエラーを確認
サーバはハングアップしていたため操作を受け付けず、電源ボタン長押しで再起動し確認しました。
起動時にエラーメッセージが表示され、
--------------------------------------------------------------
Timed out waiting for device /dev/disk/by-uuid/d2627c1e...
Dependency failed for File System Check on /dev/disk/by-uuid/d2627c1e...
Dependency failed for /home/smb...
Dependency failed for Local File Systems.
--------------------------------------------------------------
とエラーが表示された後、メンテナンスモードで起動するためパスワードを要求する画面となっていました。
サーバのドキュメントから確認すると「UUID=d3627c1e」で始まるデバイスはUSB接続の外付けHDDで、sambaサーバでデータ領域の保存を担当するHDDでfstabで/home/smbdisk2にマウントしています。
「エラーメッセージではデバイスがタイムアウトして、ファイルシステムチェックの依存関係が失敗しました」というメッセージに続き、「ローカルファイルシステムの依存関係が失敗（マウント失敗）しました。」というエラーなので、このHDDが故障してハングアップ⇒OS再起動もfstab指定のデバイスがマウント出来ないのでOSの起動が妨げられている、ということのようでした。
簡単に構成を解説
話は前後しますが、このsambaサーバではUSB接続の外付けHDDを同一型式の同容量で2台接続しており、1台をsambaサーバの共有フォルダとしてユーザに公開、もう1台はrsyncコマンドをcronで定期実行して複製を持つようにしています。
簡単に図解するとこんな感じ。
故障の発生したと思われる「UUID=d3627c1e」のHDDは正系でsambaサーバの共有フォルダとして直接ユーザから参照されているHDDです。
エラーの感じからは図中副系となっているもう一台のHDDは無事稼働しているように見受けられました。やっててよかった冗長化。
一次対処を実施
さっそくエラーが発生した側のHDDを取り外し、sambaサーバの再起動を実施してみたところ無事OSの正常起動が確認できました。
今回の問題はUSB接続の外付けHDD×2台のうち1台が故障し、OSがハングアップ、そこから起動しなくなった、という結論になりました。よって実施した対処は故障した1台を取り外し、故障ディスクが接続されていない状態でOSを起動し直す、ということになります。
ディスクのデータ自体はバックアップにて冗長化しているため（故障発生直前に保存されたデータを除けば、なのですが故障発生時刻が夜間のためユーザの利用はなかったとログから判断できましたので）データ損失はなし、という結論で、副系のディスクを正系に置き換えて、副系のディスクをメインで利用することでダウンタイムはそれほど掛からずに対処を完了することができました。
しかし、その後…
対処を完了したので帰還、しかしその数時間後に再びsambaサーバに繋がらない旨の連絡が入電。
ん？正常に起動してユーザのPCからアクセスできるところまで確認したはずなのですが、電話の向こうでは再びsambaサーバが使用できなくなったことを示すWindowsのエラーメッセージが表示されているようでした。
そのため、再びsambaサーバの設置場所へ出動、画面を確認したところ、画面には何も表示される、キーボード入力も受け付けない状態となっていました。（ハングアップ？）
故障の原因を取り除いたはずなのですが、再びハングアップが発生しています。ハングアップの原因がUSB接続の外付けHDDではなかった、ということなんでしょうか。
試しに電源ボタン長押しで電源断⇒再度電源投入でOSの正常起動を再び確認（数時間前確認した通りの動作）できたので、やっぱり問題なさそうな感じがしました。
念のためコンソールを開いて、syslogを「tail -f」で実行して画面上にsyslogメッセージがリアルタイムに表示されるようにしてしばらく様子を見ることにしました。（※ちなみにjournalの場合には前回<RaspberryPiのsyslogがなくなった? - treedown’s Report>やった「journalctl -f」ですね。）
で、そこから数時間（2時間～3時間程度）別のことで時間を使ってしまい、動作するsambaサーバのことはまったく確認していなかったのですが、気がつくと「tail -f」を実行していた画面表示が動作しなくなっていました。キーボード入力も受け付けない状態になっています。ここでハングアップしたことに気づきました。
この状態で確認してみるとWindowsクライアントからはsambaサーバの共有フォルダへ接続できなくなっていて、故障HDDを除くだけではトラブルが解消していないことを理解しました。
これでちょっと見えてきたのですが、
USB接続の外付けHDDが故障（※HDDが故障しただけなのでOSはまだ稼働中）
↓
OSが別の要因でハングアップ（HDD故障と関連なしでハングアップした）
という状況で今回のトラブルが発生したという推測ができました。
OSが稼働していればUSB接続の外付けHDDが故障していてもsambaサーバの共有フォルダを一覧で表示することはできます。ただ今回はsambaサーバ自体に接続できなくなっていました。
どうもsambaサーバの筐体であるPC本体も正常に動作しなくなっているようです。システムボードやメモリ、電源ユニットなど疑わしいところは多くあります。そこで、予め用意してあった予備機（同型式の予備機）にOSのHDDを載せ替えて稼働確認をしてみることにしました。（これでHDDの問題か、その他の部品の問題かが切り分けできるはずです。）
結果は数時間経過してもOSがハングアップすることなく継続稼働が確認できました。よってOS領域のHDDには問題なく、ハングアップの要因はメモリやシステムボード、電源ユニットなどの他の部品の問題だという結論でひとまず対処を完了しました。
続きます
いつもはエラーや障害対応で複合的な要因までを視野に入れて調査をするのですが、意外と結果として単一の問題によって引き起こされていることが多かったのですが、今回は久々に複合的な要因で発生した障害対処だったため、一つ解決したところでトラブル解消と油断してしまった面があります。再出動する羽目になってしまいました。
これでOSの稼働に問題はなくなったものの、副系のディスクを正系のディスクとして付け替えることになったので、いくつかのパスが変更になりました。自分用になりますが、次回はそのパス変更の部分を（正常なディスクを戻した際に）忘れないように記録しておこうと思います。
