Linux의 시스템 관리 및 소프트웨어 개발에서는 시스템의 C 라이브러리 및/또는 커널에서 오류가 발생하는 것이 일반적입니다. 앞으로는 이를 "errnos"("오류 번호"의 줄임말)라고 하겠습니다.
때때로 우리가 문제를 진단해야 하는 유일한 구체적인 증거는 애플리케이션 스택 추적의 오류를 설명하는 몇 가지 키워드에서 나옵니다. 복잡한 "시스템의 시스템" 시나리오에서 보다 구체적인 정보를 얻는 것은 매우 어려울 수 있습니다.
문제는 많은 오류가 모호하고 이를 정의하는 POSIX 표준으로 돌아가도 설명이 기껏해야 모호하다는 것입니다. 이러한 오류는 표준 수준에서 느슨하게 정의되어 있지만 최신 Linux의 맥락에서 많은 오류에는 매우 구체적인 원인, 오류 모드, 증상 및 문제 해결 단계가 있어야 합니다.
내가 찾고 있는 것의 예ENETUNREACH
내 지식을 바탕으로 값이 ENETUNREACH
errno #101에 대한 몇 가지 기사를 제공하겠습니다 .strerror()
Network Unreachable
가능한 한 많은 오류에 대한 자세한 정보를 제공하고 각 오류에 대해 구체적으로 확인할 사항을 제공하는 참조를 찾고 싶습니다.
나는 Linux 오류 번호 101이 Linux에서 발생한다고 생각 ENETUNREACH
합니다 Network Unreachable
.
send()
또는 와 같은 일종의 IP 스택 네트워크 호출을 수행하고 있습니다sendmsg()
.- 시스템은 라우팅 테이블에서 대상에 대한 "다음 홉"을 검색하지만 찾지 못합니다.
문제 해결, 오류 모드 및 권장 사항:
- 이는 기본적으로 대상이 유효한 IP(예: 169.254.0.0/16 또는 기타 "항상 연결할 수 없는" 네트워크가 아님)이고 시스템에 기본 경로가 있는 경우 발생하지 않습니다.
- 따라서 대상이 유효한 공용 IP 공간에 있고 시스템에 일반적으로 기본 경로가 있다는 것을 알고 있으면 이 호출이 이루어질 때 시스템에 기본 경로가 없다고 결론을 내릴 수 있습니다. (기본 경로는 목적지가 있는 경로입니다
0.0.0.0/0
. 즉, "IP 데이터그램을 보내려고 할 때마다 다음 홉은w.x.y.z
"입니다. - 기본 경로가 없는 이유는 무엇입니까? !-- 기본 경로를 제공하는 네트워크 인터페이스가 링크 레이어로 설정된 경우(
DOWN
예:ifconfig eth0 down
네트워크 케이블을 실행하거나 물리적으로 분리하는 경우 또는 클라우드 시스템에서 가상으로 이에 상응하는 경우) 시스템은 기본 경로를 삭제합니다. - 문제 범위를 좁히는 데 도움을 주는 것이 끝이 아닙니다!귀하의 상자에 일반적으로 기본 경로가 있고 유효한 IP에 도달하려고 한다고 가정하면 이는
ENETUNREACH
엔드포인트가 실제로 도달 가능한지 여부와 전혀 관련이 없습니다. 문제의 핵심은 귀하의 시스템이 이를 파악할 수 없다는 것입니다. 라우팅 테이블에서 거기로 가는 방법. - 따라서 원격 끝점은 완벽하게 괜찮을 수도 있고 다운될 수도 있습니다.
ENETUNREACH
두 경우 모두 수신할 수 있습니다.
이 모든 문제 해결 방법은 "내 머릿속에 있는" 매우 유용한 정보이지만(100.0% 정확하다고 확신할 수도 없음), 그 출처를 확인할 수는 없습니다.
POSIX.1-2001(SUSv3이라고도 함)을 살펴보았는데 man errno
이 표준이 비밀스럽게 설명하는 이유는 다음과 같습니다.
네트워크에 대한 경로가 없습니다.
매우 좋은. 하지만 내 동료들은 전환하는 방법을 모릅니다.저것애플리케이션 로그에서 이 정보를 확인하면 해당 정보를 통해 찾아야 할 항목에 대한 신뢰할 수 있는 추론을 얻을 수 있습니다.
확실하게,나는 찾고 있지 않다오직관련 정보 ENETUNREACH
. 이상적으로는 실패 모드와 원인에 대한 자세한 분석을 찾습니다.각errno, 또는 적어도 가장 일반적인 것입니다. 연결 거부, 연결 시간 초과, 네트워크 도달 불가, 대상 호스트 도달 불가, 권한 거부, 장치 공간 부족 등
내 생각엔 이것이다기초적인내 분야의 모든 사람을 위한 정보(클라우드 운영, 거의 독점적으로 Linux 가상 서버 및 매우 복잡한 시스템 사용)를 찾을 수 있지만 내가 찾을 수 있는 유일한 것은 "이것이 무엇을 의미하는지 경험을 통해, 거래의 요령으로 배워야 한다"는 것입니다. .
"완전히 이해하려면 Linux 커널과 glibc의 소스 코드를 읽어보세요"라는 말을 들은 적도 있지만,반품클라우드 운영자에게는 도움이 되지 않습니다.
클라우드 운영자가 이러한 오류 번호의 원인과 잠재적인 해결책을 찾을 수 있는 더 좋은 방법이 있습니까?