pingに応答する責任があるのはどのLinuxプロセスですか？
Linuxベースのプロセスコントローラーがあり、pingを実行できないポイントまでロックすることがあります（つまり、pingを実行すると、ネットワーク設定を変更しないとpingできなくなります）。
私は好奇心が強いのですが、実際にpingに応答する責任があるのはどのプロセス/システムですか？このプロセスはクラッシュしているようです。
カーネルネットワークスタックは、pingコマンドによって送信されたICMPメッセージを処理しています。
応答が得られない場合は、ネットワークの問題やフィルタリングのほか、ホストベースのフィルタリング/レート制限/ブラックホールなど。これは、マシンがおそらく一時的である可能性があるか、カーネルがクラッシュしている可能性があることを意味します。これはまれですが発生する可能性があり（ハードウェアの障害など）、必ずしもICMPトラフィックが原因ではありません（そのようなトラフィックでオーバーロードしようとしている）サーバーの初期の段階で、サーバーがどのように物事を維持しているかを確認するのに適したテストです。後者のカーネルクラッシュの場合は、ログファイルまたはコンソールに十分な情報があるはずです。
また、pingは、ほとんどの場合、サービスがオンラインかどうかを確認するための間違ったツールです。さまざまな理由がありますが、定義上、実際のアプリケーショントラフィックを模倣していないことが主な理由です。たとえば、Webサーバーがまだ稼働していることを確認する必要がある場合は、代わりにHTTPクエリを実行する必要があります（TCPポート80または443）。メールサーバーを確認する必要がある場合は、SMTPクエリ（TCPポート25）を実行します。 DNSサーバー、UDP および a TCPポート53へのクエリなど）.
Pingへの応答を担当するユーザーランドプロセスはありません。 Pingは、ICMPエコーパケットを送信するユーティリティにすぎません。これらは、カーネルのネットワークスタックによって受信および処理されます。
カーネル自体（ユーザープロセスではない）はICMPエコー要求メッセージに応答してICMPエコー応答メッセージを送信します。したがって、ホストがpingに応答しなくなった場合、通常は次の理由のいくつかが原因です。
ping対象のホストとホスト間のネットワーク接続が切断されている可能性があります。それは多くの理由自体が原因である可能性があります：ケーブルの物理的な損傷、ワイヤレスの場合のノイズ、ルートテーブルの破損、DDoS攻撃を受けている、間に問題のあるルーター/スイッチなどがあります。この場合、トラブルシューティングを開始しますターゲットホストで
ethtool(8)、iwconfig(8)、route(8)、ping(8)、そのルーター、tcpdump(8)などを使用します。ターゲットホスト（またはユーザーとターゲットホストの間のルーター/ファイアウォール）のファイアウォール設定により、ping（またはトラフィックトラフィック）の量が制限されている可能性があります。また、
fail2ban(8)ファイアウォールなどのツールをオンデマンドで使用することもできます。確認するには、iptables(8)を参照してください。ターゲットホストでソフトウェア/ハードウェアの誤動作が発生しました。ターゲットホストのネットワークカーネルモジュールがOOPSされているか、混乱している、またはカーネル全体でさえPANICされている可能性があります。ターゲットホストの
dmesg(8)に、または物理コンソールの画面出力としてatに関するメッセージが表示されます（物理アクセスが実際的でない場合は、serial consoleを使用する別のマシンが役立ちます。）カーネルOOPS/PANICが問題であり、より優れたドライバーを備えた新しいカーネルが役立つ場合があります。または、watchdog(8)とヘルパードライバーを使用してシステムのロックアップを回避できます。または、ハードウェアの部品を交換できます。