AI 评论 Kamailio ISSUES 4777(TLS)

链接如下https://github.com/kamailio/kamailio/issues/4777找 AI 解读了一下质量很高分享如下这段对话讨论的是 Kamailio 在运行一段时间后反复出现 TLS 相关错误tls: ssl bug #1491 workaround: not enough memory for safe operation核心结论是Kamailio 的共享内存 shm 配置太小运行 60-90 天后共享内存逐渐被消耗到低于 TLS 模块认为安全的阈值导致新的 TLS 连接被拒绝。重启后共享内存释放所以暂时恢复。1. 这个问题现象是什么用户ddas-rt报告使用 Kamailio 6.0.3启动参数是-m256-M32其中通常-m 256表示 shared memory共享内存 256 MB-M 32表示 private/pkg memory每个进程私有内存 32 MB。问题表现为Kamailio 运行 60-90 天后开始报错一旦报错新的 TLS 连接全部失败SIP over TLS 的新呼叫、新转接都无法建立已经存在的 TLS 连接似乎不受影响每次有新的 TLS 连接尝试就会打印一次错误重启 Kamailio 后问题消失但过 60-90 天又出现。错误日志是ERROR: tls [tls_server.c:232]: tls_complete_init(): tls: ssl bug #1491 workaround: not enough memory for safe operation: shm16536160 threshold1173015042. 这条日志是什么意思关键部分not enough memory for safe operation shm16536160 threshold117301504意思是当前 Kamailio 可用共享内存只剩大约16536160 bytes ≈ 15.8 MBTLS 模块要求至少要有17301504 bytes ≈ 16.5 MB当前剩余共享内存低于安全阈值所以 TLS 模块拒绝继续建立新的 TLS 连接。这个不是说系统内存不够。机器上还有很多系统内存available 26Gi但是 Kamailio 自己启动时只分配了 256 MB 的 shared memory。这个 256 MB 是 Kamailio 内部使用的内存池不会因为系统还有 26GB 可用内存就自动变大。3. 为什么重启后会恢复因为 Kamailio 重启后内部的 shared memory 会重新初始化。原来运行过程中被占用、碎片化或泄漏的共享内存都会被释放。于是 TLS 模块又能正常分配内存新 TLS 连接恢复。但如果根本原因是shared memory 配置过小某些模块长期占用共享内存或者存在缓慢增长的内存泄漏/缓存增长那么运行一段时间后还是会再次耗尽所以 60-90 天后复发。4. maintainer 的回复是什么意思henningw最后回复Already tried to increase the shared memory? Probably 256MB is just too little. Increase to 512 or 1024 MB, you are having the memory on the system.意思是你试过增加 shared memory 吗256MB 可能太小了。你的机器内存很多可以把 Kamailio 的 shared memory 增加到 512MB 或 1024MB。也就是说维护者认为目前最可能的原因是-m 256 设置太小建议改成-m512或者-m10245. 为什么日志里提到ssl bug #1491这个名字容易误导。ssl bug #1491 workaround不是说 Kamailio 自己出现了某个编号为 1491 的 bug而是 TLS/OpenSSL 相关历史问题的一个 workaround。Kamailio TLS 模块里有一段保护逻辑为了避免在共享内存不足时进入不安全状态它会在可用 shm 低于某个阈值时拒绝新的 TLS 初始化。所以真正触发原因是shared memory available too low而不是单纯的 SSL 协议错误。6. 为什么明明系统有 30GB 内存还说 not enough memory因为这里的 memory 指的是 Kamailio 的 shared memory不是 Linux 系统总体内存。系统内存30Gi total 26Gi availableKamailio shared memory-m256也就是 Kamailio 只允许自己使用 256MB 共享内存池。日志里说的是这个池快没了shm16536160剩余只有 16MB 左右。所以不是服务器没内存而是 Kamailio 的内部共享内存池太小。7. 应该怎么处理首选方案增大 shared memory把 Kamailio 启动参数从-m256-M32改成例如-m512-M32或者-m1024-M32如果机器内存充足建议直接试-m1024也就是给 Kamailio 1GB shared memory。具体修改位置取决于部署方式可能在/etc/default/kamailio或 systemd service 文件/etc/systemd/system/kamailio.service或启动脚本中。修改后重启systemctl daemon-reload systemctl restart kamailio8. 还应该继续检查什么虽然维护者建议先增大 shm但这个问题每 60-90 天出现也有可能说明存在缓慢的共享内存增长或泄漏。建议观察 Kamailio 共享内存使用情况。可以使用kamcmd core.shmmem或者kamctl fifo get_statistics shmem:看类似指标total shared memoryused shared memoryfree shared memoryreal used memorymax used memoryfragments。如果发现 shared memory 持续单调增长不下降那么可能还要查dialog 模块是否保存太多 dialogusrloc/location 表是否有过多注册TLS 连接是否异常积累htable 是否无限增长dispatcher、tm、dialog、presence 等模块是否占用大量 shm是否有内存泄漏。9. 对这段 issue 的整体解读这个 issue 的实际意思是Kamailio 运行一段时间后共享内存剩余量低于 TLS 模块安全阈值。TLS 模块为了规避 OpenSSL/SSL 相关 bug不允许继续建立新的 TLS 连接于是所有新的 SIP over TLS 连接失败。由于当前 Kamailio 只配置了 256MB shared memory而服务器本身有大量空闲内存所以建议将-m增加到 512MB 或 1024MB。简单说不是 AWS 机器内存不够 不是 TLS 证书问题 也不是单纯网络问题 而是 Kamailio shared memory 快耗尽。最直接解决方案-m1024然后持续监控 shared memory 使用趋势。