Amazon [Ec2 Linuxインスタンス]開いているファイル/ファイル記述子（FD）を追加した後、SSHは機能しません。

ディスクリプタの制限が変更されたファイルを編集した後に実行した他の操作を明確に説明しますか？ファイルの変更自体は何も変更されず、影響はありません。たとえば、ファイルの別の場所に別の文字を入力した場合、変更が正しくない可能性があります。

特に以下のことを明確にしていただけますか？

• 後でやめましたか？
• 再起動を開始しますか？

かどうかはわかりません。

• 管理コンソールで再起動してみましたか？
• 問題と一致するネットワークの問題があるかどうかを確認しましたか？
• 他の場所（別のIP）でログインしようとしましたか？

すべてが正常に機能し、他の方法ではシステムに戻ることができない場合は、次のAWSドキュメントに従ってください。アクセスできないLinuxインスタンスを回復する方法。

仮想ハードドライブを新しいシステムの新しいドライブに交換し、新しいシステムの「古い」ハードドライブを調べて、その過程で重要なすべてを回収するようです。以前のログビューを含めるシステムに実際にどのような影響があるかを確認してください。

修正する- 先に限度を増やした時も同様のことが起こったというコメントがありました。最大nofile設定が1048576（例：1024 * 1024、2 ^ 20）であることをテストし、他の場所でヒントを見つけました。 Linuxボックスでより高い値を使用すると、最も高い1024に戻りますが、問題は発生しません。おそらく、あなたは寛大ではなく、制限を超えたか、間違った制限を設定できなかったことを致命的と見なしてログインできないAWSディストリビューションを使用している可能性があります。

注 – 変更はすぐには適用されません。次回のログイン時および/または新しくログインしたセッションから再開したすべてのプロセス、または再起動後にすべてのプロセスに適用されますが、遅すぎます。

問題を再現できないため、ボックスにアクセスし続ける方法がわかりません。再起動しないとrootとしてsftpが機能する可能性がありますが、再起動後にその可能性がなくなることがあります。

su次回は、rootとしてログインできないか再利用できない場合に備えて、root SSHセッションの実行画面をアクティブにしておくことをお勧めします。おそらくmoshを介して接続されている可能性があります。これは、将来のログインに影響を与えるシステムの内容を変更するときに重要です。

戻ることができない場合に備えて、古いファイルを復元するために30分後にcronjobをスケジュールすることを検討することもできます。ただし、これらのファイルは変更自体の前に準備する必要があり、実行がブロックされる可能性があります。

残念ながら、リモートアクセス方法のいずれも機能しない場合（sftpをrootとして使用するのは悪い考えです）、上記のAWSドキュメントを参照して別のインスタンスを介してホストからデータを復元する必要があるかもしれません。

EC2 AMIに関する問題のようです。この問題を解決するには。

1. EC2インスタンスからEBSを分離する
2. fs.nr_open = 4000000追加する/etc/security/limits.conf fs.file-max = 4000000 fs.nr_open = 4000000
3. EBSをEC2インスタンスに接続する
4. EC2を再起動してログインします。