LinuxインスタンスのVNC使用およびレスキューモードを使用したトラブルシューティング

Recent Pages

LinuxインスタンスのVNC使用およびレスキューモードを使用したトラブルシューティング

最終更新日:2022-07-21 18:01:18

通常、Linuxシステムの問題のほとんどは、VNC方式とレスキューモードを使用したトラブルシューティングで解決することができます。ここでは、この2つの方法を用いて、SSHログインができない、システムの障害発生などに対しトラブルシューティングを行う方法についてご説明します。インスタンスのトラブルシューティングと修復の方法について学ぶことができます。
トラブルシューティングツール
VNCログインは、Webブラウザを使ってCVMにリモート接続する方法であり、通常は、正常なSSHリモートログインができない場合に使用します。VNCログイン方式を使用すると、CVMのステータスの直接観察やシステム内の設定ファイルの変更といった操作が可能です。
レスキューモードは、通常、Linuxシステムが正常に起動しない場合やVNCでログインできない場合に使用します。一般的なユースケースとしては、fstab設定の異常、重要なシステムファイルの欠落、lib動的ライブラリファイルの破損/欠落などがあります。
問題の特定および処理
VNC方式によるSSHログインのトラブルシューティング方法
現象の説明
SSHを使用してLinuxインスタンスにログインすると、下図のように、「ssh_exchange_identification: Connection closed by remote host」というエラー情報が表示されます。
﻿
﻿
考えられる原因
kex_exchange_identificationフェーズでのconnection resetエラーは、通常、ssh関連のプロセスが開始されたことを意味しますが、sshd設定ファイルの権限が変更されているなど、設定に異常がある可能性があります。
解決方法
﻿処理手順 を参照し、sshdのプロセスをチェックして、問題を特定して解決します。
処理手順
以下の手順を参照し、VNCを使用してLinuxインスタンスにログインします。
1. 下図に示すよ
うに、CVMコンソール にログインし、ログインしたいLinux CVMを見つけて、右側のログインをクリックします。
﻿
﻿
2. 開いた「標準ログイン | Linuxインスタンス」ウィンドウで、VNCログインをクリックします。
3. 「login」の後にユーザー名を入力し、Enterを押します。「Password」の後にパスワードを入力し、Enterを押します。下図のようになれば、ログインに成功しています。
 
﻿
﻿
4. 以下のコマンドを実行し、sshdプロセスが正常に動作しているか確認します。
ps -ef | grep sshd
下図のような結果が返されれば、sshdプロセスは正常です。
﻿
﻿
5. 次のコマンドを実行し、エラーの原因を確認します。
sshd -t
下図のような情報、"/var/empty/sshd must be owned by root and not group or world-writable.
"が返された場合、エラーの原因は、/var/empty/sshd/の権限の問題である可能性があります。
﻿

また、下図に示すように、/var/log/secureログにあるエラー情報を確認することで、トラブルシューティングを支援することができます。
﻿
﻿
6. 次のコマンドを実行して、/var/empty/sshdディレクトリの権限を確認します。
ll -d /var/empty/sshd/
下図のような結果が返されます。権限が777に変更されたことがわかります。
﻿
﻿
7. 次のコマンドを実行し、/var/empty/sshd/ファイル権限を変更します。
chmod 711 /var/empty/sshd/
﻿SSHを使用してLinuxインスタンスにログイン を参照してテストを行うと、正常にインスタンスにリモートログインできるようになります。
VNC方式によるLinuxシステムの起動失敗のトラブルシューティング
現象の説明
SSHでLinux CVMへの正常なリモートログインができず、VNC方式でログインすると、システムの起動失敗が確認され、下図のように「Welcome to emergency mode」というメッセージが表示されます。
﻿
﻿
考えられる原因
/etc/fstabの設定が不適切であることが原因という可能性があります。
例えば、/etc/fstabにおいてディスクがデバイス名で自動的にマウントされるように設定されている場合も、CVMを再起動するとデバイス名が変わってしまい、システムが正常に起動しなくなることがあります。
解決方法
﻿処理手順 を参照して/etc/fstab設定ファイルを修復し、サーバーを再起動してから検証します。
処理手順
1. ﻿処理手順1 を参照し、VNCを使用してLinuxインスタンスにログインします。
2. 下図に示すように、VNCインターフェースに進み、現象の説明 のようなインターフェースが表示されたら、rootアカウントのパスワードを入力し、Enterを押してサーバーにログインしてください。入力されたパスワードは、デフォルトでは表示されません。
﻿
﻿
3. システムに入った後、以下のコマンドを実行し、fstabファイル内のボリュームラベル情報が正しいかどうかを確認します。
lsblk
下図のような結果が返されます。ファイル内ボリュームラベル情報に誤りがあります。
﻿
﻿
4. 以下のコマンドを実行し、fstabファイルのバックアップを取ります。
cp /etc/fstab /home
5. 以下のコマンドを実行し、VIエディタを使用して/etc/fstabファイルを開きます。
vi /etc/fstab
6. 下図に示すように、iを押して編集モードに入り、カーソルを設定エラーの行の先頭に移動させ、#を入力して行の設定についてコメントアウトします。
﻿
﻿
7. Escを押して:wqと入力した後、Enterを押して設定を保存し、エディタを終了します。
8. コンソールからインスタンスを再起動します。詳細については、インスタンスの再起動 をご参照ください。
9. 正常に起動、ログインできるかどうかを検証します。
レスキューモードによるLinuxシステムの起動失敗のトラブルシューティング
現象の説明
下図に示すように、Linuxシステムが再起動後に起動せず、多数のFAILED起動失敗の項目が情報に表示されています。
﻿
﻿
考えられる原因
binファイルやlibファイルなど、重要なシステムファイルの欠落が原因で起動に失敗することがあります。
解決方法
﻿処理手順 を参照し、コンソールからインスタンスレスキューモードに入り、トラブルシューティングと修復を行います。
処理手順
1. レスキューモード開始前に、誤操作などによる影響を防止するため、インスタンスをバックアップすることを強くお勧めします。CBSでは スナップショットの作成 を介してバックアップでき、ローカルシステムディスクでは カスタムイメージの作成 を介してイメージをバックアップできます。
2. 下図に示すように、CVMコンソール にログインし、「インスタンス」ページで、インスタンスが配置されている行の右側のその他 > 運用保守と検査 > レスキューモードの開始を選択します。
﻿
﻿
3. 下図に示すように、ポップアップした「レスキューモードの開始」ウィンドウで、レスキューモード中にインスタンスにログインするためのパスワードを設定します。
﻿
﻿
4. レスキューモードの開始をクリックすると、インスタンスのステータスが「レスキューモードの開始」に変わります。下図のように、通常、この処理は数分以内に完了します。
﻿

レスキューモードが正常に開始された後、下図に示すように、インスタンスのステータスが赤いエクスクラメーションマーク付きの「レスキューモード」に変更します。
﻿
﻿
5. rootアカウントおよび ステップ3 で設定したパスワードを使用し、次の方式でインスタンスにログインします。
インスタンスにパブリックIPが有る場合は、SSHを使用してLinuxインスタンスにログイン をご参照ください。
インスタンスにパブリックIPがない場合は、VNCを使用してLinuxインスタンスにログイン をご参照ください。
6. ここでは、VNC方式によるログインを例に取ります。ログインに成功したら、下記のコマンドを実行し、システムディスクのルートパーティションをマウントします。
説明：
レスキューモードでのインスタンスのシステムディスクデバイス名はvda、ルートパーティションはvda1で、デフォルトではマウントされていません。
mkdir -p /mnt/vm1
mount /dev/vda1 /mnt/vm1
実行が完了すると、下図のような結果が返されます。
﻿
﻿
7. マウントに成功したら、元のシステムルートパーティション内のデータを操作できるようになります。
mount -o bindコマンドを使用して元のファイルシステムのサブディレクトリの一部をマウントし、かつchrootコマンドを使用して指定のルートディレクトリでコマンドを実行することもできます。具体的な操作コマンドは次のとおりです。
mount -o bind /dev /mnt/vm1/dev
mount -o bind /dev/pts /mnt/vm1/dev/pts
mount -o bind /proc /mnt/vm1/proc
mount -o bind /run /mnt/vm1/run
mount -o bind /sys /mnt/vm1/sys
chroot /mnt/vm1 /bin/bash
chrootコマンドを実行する場合。
エラー情報がなければ、cd /コマンドで続行できます。
下図のようなエラー情報が表示された場合は、ルートディレクトリが正常に切り替えられていないので、cd /mnt/vm1を実行してルートパーティションのデータを確認します。
﻿
﻿
8. 下図に示すように、このコマンドは、元のシステムルートパーティションの/usr/binディレクトリにある、削除されたすべてのファイルを表示することができます。
﻿
﻿
9. この時点で、同じOSの正常なマシンを作成して以下のコマンドを実行し、正常なシステムの/usr/binディレクトリにあるファイルを圧縮して異常なマシンへリモートでコピーすることができます。
正常なマシン：以下のコマンドを順次実行します。
cd /usr/bin/ && tar -zcvf bin.tar.gz *
scp bin.tar.gz root@異常インスタンスip：/mnt/vm1/usr/bin/
説明：
パブリックIPをお持ちの方はパブリックネットワーク経由でコピーできますが、パブリックIPをお持ちでない方は、プライベートネットワーク経由でコピーする必要があります。
﻿
﻿
﻿
異常なマシン：レスキューモードでは、以下のコマンドが順次実行されます。
cd /mnt/vm1/usr/bin/
tar -zxvf bin.tar.gz
chroot /mnt/vm1 /bin/bash
実行結果は、下図のように示されます。
﻿
﻿
﻿
10. 下図に示すように、インスタンスの修復が完了したら、インスタンスが配置されている行右側のその他 > 運用保守と検査 > レスキューモードの終了を選択します。
﻿
﻿
﻿
11. レスキューモード終了後、インスタンスはシャットダウン状態になり、起動後にシステム検証が行われます。下図のようになった場合、システムはすでに復元されています。
﻿
﻿
﻿
﻿