私はPG、MariaDB、sidekiq、apache httpdを実行しているCentOS 7 VMを使用しています。時々私のログは次のエラーでいっぱいです。
unable to resolve address: System error
WARN: Mysql2::Error::ConnectionError: Unknown MySQL server host 'mariadb' (16)
WARN: PG::ConnectionBad: could not translate host name "postgres" to address: System error
WARN -- : Unable to record event with remote Sentry server (Errno::EBUSY - Failed to open TCP connection to o383708.ingest.sentry.io:443 (Device or resource busy - getaddrinfo)):
Sentinelサービスを除くすべてのホストは、/ etc / hostsファイルで127.0.0.1に設定されています。
ホスト名のpingはコンソールで機能しているようで、これらのエラーは実行中にさまざまなアプリケーションログに表示されます。
lsof | wc -l => 700k(最大1.6M)
VMにはかなりの負荷がかかりませんでした（平均負荷は10％）。エクスプロイトやルートキットなどはありません。
私のホストファイル：
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
127.0.0.1 mariadb
127.0.0.1 postgres
127.0.0.1 mongodb
127.0.0.1 redis
127.0.0.1 memcached
127.0.0.1 socketcluster
/etc/nsswitch.comの内容
passwd: files sss
shadow: files sss
group: files sss
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
bootparams: nisplus [NOTFOUND=return] files
ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files sss
netgroup: nisplus sss
publickey: nisplus
automount: files nisplus sss
aliases: files nisplus
何が起こっているのか知っている人はいますか？ getaddrinfoがホストファイルを開くことができないのはなぜですか？ ？ ？
この問題に賞金を追加してください。自由にしてはいけません。
ベストアンサー1
私はあなたが議論を通して正しい根本的な原因を見つけたと思います/etc/hosts。実際、それらの一部は失敗するホストのドメインが正しく設定されました。そして最初に表示されるホストは、nsswitch.conf電源投入前/電源投入中にエラーが発生したことを示します/etc/hosts。
最初の障害は、コマンドラインで問題を再現することです。
このサービスが実行されているか調べてみましょう。マウントネームスペース。 Centosがサービスにもっとマウントネームスペースを使用していることを読んだ。何か変わったので、その理由を漠然と覚えています/etc/が、完全に間違っている可能性があります。したがって、mariadbの場合は、次の3つの出力が一致していることを確認してください。
# systemd
ls -lh /proc/1/ns/mnt
# console
ls -lh /proc/self/ns/mnt
# mariadb / mysql
ls -lh /proc/$(pidof mysqld)/ns/mnt
mariadbがコンソールと一致しない場合は、別の名前空間にあります。次のように名前空間を入力できる必要があります。
nsenter -mt $(pidof mysqld) /bin/bash
これにより、何が起こっているのかをさらに詳しく調べることができます。 MySQLと同じ問題のあるコマンドラインエクスペリエンスを提供できることを願っています。
ノート問題が一時的な場合は、「停止」期間中にこれを行う必要があります。
次のステップは、正確に何が失敗しているのかを調べることです。現在の推測はこれ/etc/hostsですが、その前に別のファイルを読みました。本当に便利なコマンドはストレス
コマンドラインでエラーを再現できる場合は、straceと単純なコマンドを使用してください。たとえば、pingコマンドが失敗した場合は、次のコマンドで生成された出力ファイルを確認してください。
strace -o output_file ping mariadb
エラーを再現できない場合は、mariadb自体を追跡できます。出力ファイルは非常に大きいですが、利用可能な内容を提供できます。
strace -o output_file -p $(pidof mysqld)
strace 出力があれば、失敗した正確なシステム呼び出しとコンテキストを取得できます。探しているエラーメッセージに従って忙しい:
grep -nC5 EBUSY output_file
これにより、幸運のために両側に5行で失敗したシステムコールが表示されます。これには少し法医学的な作業が必要になるかもしれませんが、正確に何が詰まっているのかを教えてくれます。