すべてのプロダクト
Search

このプロダクト

    :Linux インスタンスでのリモート接続の失敗または "Too many open files" エラーの解決

    ドキュメントセンター

    :Linux インスタンスでのリモート接続の失敗または "Too many open files" エラーの解決

    最終更新日:Mar 01, 2026

    問題の説明

    • リモート接続の失敗：

      • Secure Shell (SSH) またはワークベンチを使用して Elastic Compute Service (ECS) インスタンスに接続すると、接続が拒否されるかタイムアウトし、セッションを確立できません。

      • Virtual Network Computing (VNC) 経由でログインする際、正しいユーザー名とパスワードを入力した後に「システムエラー」メッセージが表示され、ログインに失敗します。

    • アプリケーションエラー：

      アプリケーションのログまたはコマンドラインの出力に「Too many open files」エラーが表示されます。image

    原因

    この問題は、nofile リソース制限が厳しすぎることが原因で発生します。/etc/security/limits.conf ファイル内の nofile パラメーターは、プロセスが開くことができるファイルの最大数を定義します。この値が低すぎると、制限を超えたプロセスはエラーを報告するか、ログインに失敗します。

    解決策

    インスタンスにまだログインできる場合は、設定ファイルを直接変更できます。ログインできない場合は、システムディスクを別のインスタンスにアタッチして修復する必要があります。

    インスタンスにログインできる場合

    1. root ユーザーとして ECS インスタンスにログインします。

      1. ECS コンソール - インスタンスページに移動します。ページの左上隅で、対象インスタンスのリージョンとリソースグループを選択します。

      2. 対象インスタンスの詳細ページに移動し、[接続] をクリックしてから [ワークベンチ] を選択します。画面の指示に従って root ユーザーとしてログインし、ターミナルを開きます。

    2. 設定ファイルを変更します。

      /etc/security/limits.conf ファイルを編集します。hard nofile と soft nofile パラメーターの値をデフォルトの 65535 に変更し、ファイルを保存して終了します。

      * soft nofile 65535
* hard nofile 65535
root soft nofile 65535
root hard nofile 65535

      • * はすべての標準ユーザーに適用され、root は root ユーザーに適用されます。

      • hard nofile：オープンできるファイル数のハードリミットです。この値は、カーネルパラメーター /proc/sys/fs/nr_open によって設定された制限を超えることはできません。この制限を超えると、インスタンスにログインできなくなる可能性があります。

      • soft nofile：オープンできるファイル数の現在の制限です。この値は hard nofile の制限を超えてはなりません。超えた場合、この設定は無視されます。

        soft nofile の値が hard nofile の値より高く設定されている場合、hard nofile の値が有効な制限として使用されます。

    3. 新しい設定を適用します。

      1. 対象のユーザーアカウントで ECS インスタンスからログアウトし、再度ログインして変更を適用します。

      2. sudo ulimit -n を実行します。出力が 65535 であれば、nofile 制限が更新されたことを確認できます。

    4. 関連するアプリケーションを再起動し、正常に機能することを確認します。

    インスタンスにログインできない場合

    重要

    システムディスクの過去のスナップショットが存在する場合は、まず 新しいスナップショットを作成して現在のデータをバックアップします。次に、過去のスナップショットを使用してシステムディスクをロールバックし、インスタンスが復元されたことを確認します。

    過去のスナップショットが利用できない場合は、問題のあるインスタンスと同じゾーンにある正常な Linux インスタンスが必要です。問題のあるシステムディスクを正常なインスタンスにデータディスクとしてアタッチし、nofile パラメーターを変更します。

    1. システムディスクをデタッチします。

      問題のあるインスタンスが [停止済み] 状態であることを確認し、次の手順に従います：

      1. 誤操作によるデータ損失を防ぐため、システムディスクのスナップショットを作成して現在のデータをバックアップすることを推奨します。

      2. ECS コンソール - インスタンスページに移動します。ページの左上隅で、対象インスタンスのリージョンとリソースグループを選択します。

      3. 問題のあるインスタンスの ID をクリックして [インスタンスの詳細] ページに移動し、[ブロックストレージ] タブをクリックします。

      4. [システムディスク] セクションで、[操作] 列を見つけ、更多 > [デタッチ] を選択します。

      5. [クラウドディスクのデタッチ] ダイアログボックスで、情報を確認して [OK] をクリックします。インスタンスのステータスが [システムディスクなし] に変わると、ディスクは正常にデタッチされています。

    2. 正常なインスタンスにディスクをデータディスクとしてアタッチします。

      正常なインスタンスが [実行中] 状態であることを確認し、次の手順に従います：

      1. 問題のあるシステムディスクを正常なインスタンスにアタッチします。

        1. 正常なインスタンスの ID をクリックして、その詳細ページに移動します。

        2. [ブロックストレージ] タブをクリックし、[クラウドディスクのアタッチ] をクリックします。

        3. [インスタンスにアタッチ] ページで、[ディスク] セクションでデタッチしたシステムディスクを選択し、[次へ] をクリックします。

        4. [ディスクのパーティション分割、ファイルシステムの作成とマウント] ページで、[後で設定] を選択してアタッチを完了します。

      2. [接続] をクリックし、[ワークベンチ] を選択します。画面の指示に従って root ユーザーとしてログインし、ターミナルを開きます。

      3. ファイルシステムをマウントします。

        1. 問題のあるディスクのパーティション名を特定します。

          lsblk -f
          vda                                                      
├─vda1                                                   
├─vda2 vfat         7938-FA03                            /boot/efi
└─vda3 ext4   root  33b46ac5-7482-4aa5-8de0-60ab4c3a4c78 /
vdb                                                      
├─vdb1                                                   
├─vdb2 vfat         7938-FA03                            
└─vdb3 ext4   root  33b46ac5-7482-4aa5-8de0-60ab4c3a4c78

          この例では、問題のあるディスクは vdb で、そのルートパーティションは vdb3 です。これがマウントする必要のあるパーティションです。パーティションは次のように説明されます：

          • vdb1/vdb2：システムブートファイルが含まれており、無視できます。

          • vdb3：オペレーティングシステムファイルとデータが含まれています。このパーティションをマウントする必要があります。

        2. ディレクトリを作成し、ファイルシステムをマウントします。

          mkdir <mount_directory> && sudo mount /dev/<partition_name> <mount_directory>

          パラメーター

          説明

          <partition_name>

          これを、前のステップで特定した問題のあるディスクのルートパーティション名に置き換えます。

          <mount_directory>

          カスタムのマウントディレクトリです。/ で始まる空のパスである必要があります。名前はカスタマイズできますが、一意である必要があります。

          重要

          空でないディレクトリでは、元のファイルは非表示になり、読み取ることができません。注意して進めてください。

          たとえば、対象のパーティション vdb3 を /test という名前の新しいディレクトリにマウントするには、mkdir /test && sudo mount /dev/vdb3 /test を実行します。

        3. ファイルシステムがマウントされたことを確認します。

          lsblk コマンドを実行します。対象のパーティションにマウントディレクトリ (MOUNTPOINT) がリストされていれば、ファイルシステムは正常にマウントされています。

    3. 設定ファイルを変更します。

      <mount_directory>/etc/security/limits.conf ファイルを編集用に開きます。hard nofile と soft nofile パラメーターの値をデフォルトの 65535 に変更し、ファイルを保存して終了します。

      * soft nofile 65535
* hard nofile 65535
root soft nofile 65535
root hard nofile 65535

      • * はすべての標準ユーザーに適用され、root は root ユーザーに適用されます。

      • hard nofile：オープンできるファイル数のハードリミットです。この値は、カーネルパラメーター /proc/sys/fs/nr_open によって設定された制限を超えることはできません。超えた場合、再起動後にインスタンスにログインできなくなる可能性があります。

      • soft nofile：オープンできるファイル数の現在の制限です。この値は hard nofile の制限を超えてはなりません。超えた場合、この設定は無視されます。

        soft nofile の値が hard nofile の値より高く設定されている場合、hard nofile の値が有効な制限として使用されます。

    4. ディスクを元の ECS インスタンスにシステムディスクとして再度アタッチします。

      1. ファイルシステムをアンマウントします。

        <mount_directory> を実際のマウントパスに置き換えます。

        umount <mount_directory>
        この例では、umount /test を実行します。

      2. 修復したシステムディスクをデタッチします。

        1. ECS コンソールに戻り、正常なインスタンスの詳細ページの [ブロックストレージ] タブに移動します。

        2. 修復したシステムディスクの [操作] 列で、[デタッチ] をクリックします。

        3. [クラウドディスクのデタッチ] ダイアログボックスで、[OK] をクリックします。

      3. 修復したシステムディスクを元のインスタンスに再度アタッチします。

        1. 問題のあるインスタンスの詳細ページの [ブロックストレージ] タブに移動し、[クラウドディスクのアタッチ] をクリックします。

        2. [インスタンスにアタッチ] ページで、[ディスク] セクションで修復したシステムディスクを選択し、[ログイン資格情報] を設定して、[次へ] をクリックします。

        3. [ディスクのパーティション分割、ファイルシステムの作成とマウント] ページで、[後で設定] を選択してアタッチを完了します。

      4. ECS インスタンスを起動します。

    5. 元の ECS インスタンスにログインし、問題が解決されたことを確認します。

    推奨事項

    • コアシステムファイルの慎重な取り扱い：コアシステムファイルを変更する前に、必ずスナップショットを作成してデータをバックアップしてください。変更が必要であることを確認し、潜在的なリスクを理解してください。詳しくないシステムパラメーターは変更しないでください。

    • モニタリングとアラート：コアシステムの安定性とセキュリティを確保するため、すべてのコアインスタンスで ulimit -n 構成に対する監視メカニズムを導入することを検討してください。ulimit -n の実行時の値を期待される構成と定期的に照合することで、システムリソースの制限が基準を満たしていることを確認し、不正な変更に関するアラートをタイムリーに受信できます。