Erlang/OTP 26.2.5.4版本中inet_gethost挂起问题的分析与解决

在Erlang/OTP 26.2.5.4版本中，部分用户报告了一个严重的问题：应用程序会在随机时间点无限期挂起在inet_gethost 4调用上。这个问题在容器化环境中尤为明显，当容器没有设置CPU限制时，大约有10-30%的容器会出现这种挂起现象。

问题现象

受影响的应用程序在启动过程中会随机挂起，通过检查进程树可以看到系统卡在inet_gethost相关的调用上。inet_gethost是Erlang VM默认的解析器后端，它通过启动最多4个工作子进程来以线程安全的方式调用操作系统解析器。

值得注意的是，这个问题有一个非常特殊的缓解方式：当为容器设置CPU限制时，问题就不会出现。这个现象最初让开发者感到困惑，因为它似乎与网络解析没有直接关联。

问题根源

经过深入调查，发现问题实际上与Erlang的crypto模块有关，而非表面上的网络解析问题。在OTP-26.2.5.4版本中，crypto:supports(curves)函数存在一个bug，当多个Erlang进程首次调用它时，可能会导致调度线程阻塞。

这个bug解释了为什么设置CPU限制可以缓解问题：CPU限制可能改变了进程调度的时序，避免了多个进程同时首次调用crypto:supports(curves)的情况。

解决方案

这个问题在OTP-26.2.5.5版本中得到了修复。修复的变更包括：

1. 修正了crypto:supports(curves)函数的线程安全性问题
2. 确保多个Erlang进程首次调用该函数时不会导致调度线程阻塞

验证与确认

epgsql项目的CI测试验证了这个问题的存在和修复效果：

• 在OTP-26.2.5.4上，测试会因超时而失败
• 在OTP-26.2.5.3和OTP-26.2.5.5上，测试都能正常通过

进一步的测试还发现，当问题发生时，不仅应用程序会挂起，连远程shell连接也会受到影响，这表明整个VM的调度可能受到了阻塞。

结论与建议

对于遇到类似问题的用户，建议：

1. 立即升级到OTP-26.2.5.5或更高版本
2. 如果暂时无法升级，可以考虑设置CPU限制作为临时解决方案
3. 在容器化环境中部署Erlang应用时，建议始终进行充分的版本测试

这个问题提醒我们，表面现象（如网络解析挂起）可能与实际根源（如加密函数问题）相距甚远，在排查复杂系统问题时需要保持开放思维。