ルートによって予約されたスペース（通常5％）を除いた場合、/tmpが実際に100％いっぱいで、空きバイトが0バイトの場合、なぜSSH経由でマシンにログインできなかったのか? 「フォークできません」というエラー メッセージのみが表示されました。
/tmp が 100% いっぱいの場合でもマシンにログインできるように、ssh クライアントにパラメータはありますか?
更新: 再起動は実際には選択肢ではありません:\
答え1
/tmpフルサイズが問題だとは思いません。fork()実行中のプロセスが多すぎる場合にのみ、システム コールがその特定のエラーで失敗します。
ulimit を設定していますか?
コンソールにアクセスできない場合、できることはほとんどありません...
答え2
/tmp が SWAP スペースによってバックアップされているケースを見たことがあります。そのため、スワップを行っていて、/tmp アクティビティが大量にある場合は、SWAP スペースが不足してこのメッセージが表示される可能性が非常に高くなります。
メモリが不足している場合は、再起動する以外に選択肢はほとんどありません。メモリ キラーが動作している場合もありますが、一部のプロセスが無差別に終了され、重要なプロセスも終了する可能性があります。
もう 1 つは、1 つ (または複数) のプロセスがプロセス テーブルをいっぱいにしていることです。使用可能なスロットがなくなると、このメッセージも表示されます。この場合の解決策は、ログインできることを前提として、この状態を引き起こしているプロセスを検索して破棄することです。ログインできない場合は、再起動が唯一の選択肢です。
最後に、もちろん、マシンのソフトウェアまたはハードウェアに深刻な問題が発生している可能性があります。これが、あなたが説明している状況を引き起こしている可能性があります。
答え3
多くのシステムでは、/tmpは RAM 上に存在する仮想ファイル システムです。設定方法によっては、これをいっぱいにすると RAM がすべて消費され、新しいプロセスを初期化するためのメモリが不足する可能性があります。
ご想像のとおり、これはssh事後的に回避できるものではありません。ただし、/tmpこれほど大きくならないように調整することで、将来的にこのような事態が発生するのを防ぐことができます。
答え4
回避策として、再起動後に ssh を試してください。以前、同様の問題が発生しましたが、システムの再起動後に自動的に解決されました。