トラブルシューティング: ストレージの問題
授業中に発生したトラブルとして、VMのストレージに起因する問題が報告されました。 今後も発生することが懸念されるので、以下に対処方法をまとめます。
まとめ
VMのストレージに関する問題が生じたとき、以下の手順で対処してください。
networkVMにログインする~/.vscode-*でマッチするディレクトリを全部削除するvscodeのリモートで再度接続を試みる
これだけではわかりにくいと思います。以下の説明を確認し、該当する場合には対応してください。
何が起きるのか?
授業内で仮想マシンに対してvscodeで繋いだときに、急に接続できないという状況が発生することがあります。 この時、vscodeのリモート接続に関して、以下のようなメッセージが確認できる場合があります。
vscodeのリモート接続エラー出力
この時、出力をよく確認してみると、 no space left on device というメッセージが含まれていることがあります。
これは、VM(network)のストレージがいっぱいになっていることを示しています。
なにが原因なのか?
原因として考えられるのは、Visual Studio Code(vscode)のアップデートによるものです。
vscodeは度々アップデートが行われ、さらにリモート接続拡張もアップデートが発生しています。
特にリモート接続拡張のアップデートが発生すると、リモート(network)側も新たに対応する接続用プログラムが必要となります。
この時、古くなった接続用プログラムが残ったまま、新しい接続用プログラムがインストールされてしまいます。
このプログラム、ひとつがざっくり200MB程度のサイズがあり、数回のアップデートにより積み重なっていくことになります。
結果として各自のホームディレクトリ(~、/home/linux)部分のストレージがいっぱいとなり、no space left on device というエラーが発生します。
確認方法
実際にストレージがいっぱいになったかの確認方法は、以下の操作で確認できます。
networkVMにログインします。 a. ターミナル(もしくはPowerShell)を開きます。 b.ssh networkと入力し、Enterを押します。 c. パスワードを聞かれたらいつものパスワードを入力します(画面には表示されません)。Linux側のプロンプト(
$)が確認できたら、df -h ~(最後はチルダ記号)を入力し、Enterで実行します。
この操作により、以下のように「ホームディレクトリを含むストレージの使用状況」が出力されます。
$ df -h ~
ファイルシステム サイズ 使用 残り 使用% マウント位置
/dev/mapper/linuxstudy--vg-root 14G 2.2G 11G 17% /
この場合は使用率17%なので問題ありません。 もし、以下のように「使用率が100%(に近い状態)」となっている場合は、ストレージがいっぱいになっています。
$ df -h ~
ファイルシステム サイズ 使用 残り 使用% マウント位置
/dev/mapper/linuxstudy--vg-root 14G 13G 0 100% /
対応方法
ストレージがいっぱいになった原因は前述の通りで、vscodeのリモート接続拡張のリモート側プログラムの残骸が原因です。 よって、ここを削除するとストレージが解放され、再度vscodeのリモート接続が可能になります。
具体的には、以下の手順で対応します。
networkVMにログインする(手順は前述の通り)。~/.vscode-*でマッチするディレクトリを全部削除する。vscodeのリモートで再度接続を試みる。
以下のコマンドを実行することで、~/.vscode-*でマッチするディレクトリを削除できます。
$ rm -rf ~/.vscode-*
$ df -h ~ # 正常に機能したか、容量の変更で確認する
ファイルシステム サイズ 使用 残り 使用% マウント位置
/dev/mapper/linuxstudy--vg-root 14G 2.2G 11G 17% /
これでストレージの使用率が減少し、vscodeのリモート接続が再び可能になります。
警告
必ずリモートに接続した状態で行ってください。 うっかりログインしていない状態で実行すると、ホスト(WindowsやmacOS)側のvscodeの設定がごっそり消されます。
著者(佐藤)はこの検証を行う際にうっかりやりました(1敗)。
根本的な解決方法はあるのか?
ホームディレクトリの容量を配布時点で増やすことで緩和可能です。 とはいえ使い続けていると結局はいっぱいになるため、根本的な解決方法はありません。