在 Linux 上的系统管理和软件开发中，经常会遇到来自系统 C 库和/或内核的错误，从现在起我将其称为“errnos”（“错误号”的缩写）。
有时，我们诊断问题的唯一具体证据来自应用程序堆栈跟踪中描述错误的几个关键字。在复杂的“系统的系统”场景中获取更具体的信息可能极其困难。
问题是许多 errno 都是模糊的，甚至回到定义它们的 POSIX 标准，它们的描述充其量也是含糊不清的。我知道这些错误在标准级别上被松散地定义，但在现代 Linux 的背景下，许多错误应该有非常具体的原因、故障模式、症状和故障排除步骤。
我所寻求的例子ENETUNREACH
根据我自己的知识，我将为您提供一些有关 errno #101, 的文章ENETUNREACH，其strerror()值为Network Unreachable。我想找到一份参考资料，提供有关尽可能多的错误的详细信息，并为每个错误提供具体的检查内容。
我相信 Linux errno 101, ENETUNREACH,Network Unreachable会在 Linux 上发生：
- 您正在执行某种 IP 堆栈网络调用，例如
send()或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 的源代码以全面了解”之类的评论，但是还对云运营商没有帮助。
对于云运营商来说，是否有更好的方法来查找这些错误号的原因和潜在的解决方案？