저는 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의 경우 다음 세 가지의 출력이 일치하는지 확인하세요.
# 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줄과 함께 실패한 시스템 호출이 표시됩니다. 이를 위해서는 약간의 법의학 작업이 필요할 수 있지만 정확히 무엇이 막혔는지 알려줄 것입니다.
답변2
이는 4096개의 inotify 핸들러만 있기 때문입니다. 한도를 늘렸더니 문제가 사라졌습니다.
fs.file-max = 131070
fs.inotify.max_user_watches = 65536