OpenSips运行2-3天突发崩溃，求助排查问题及系统选型建议

我来帮你拆解这些日志，并一步步教你排查OpenSips的崩溃问题：

咱们逐个解析关键日志条目：

• CRITICAL:core:receive_fd: EOF on 17：文件描述符17对应的通信通道（可能是网络连接或内部进程间通信）意外断开了，这是崩溃前的预警信号。
• INFO:core:handle_sigs: child process 14090 exited by a signal 11：信号11是SIGSEGV（段错误），这是崩溃的直接原因——子进程访问了不属于它的内存地址，触发了系统的强制终止。
• INFO:core:handle_sigs: core was generated：系统生成了core dump文件，这是排查的核心依据，它保存了进程崩溃瞬间的内存状态。
• INFO:core:handle_sigs: terminating due to SIGCHLD：主进程检测到子进程退出后，也跟着终止了，导致整个OpenSips服务崩溃。
• INFO:core:sig_usr: signal 15 received：最后收到的SIGTERM信号，大概率是系统或监控工具在服务崩溃后发送的收尾终止信号。

1. 优先分析core dump文件 #

这是定位段错误根源最有效的方法：

• 先确保Ubuntu开启了core dump：
  • 临时生效：执行ulimit -c unlimited，然后重启OpenSips
  • 永久生效：编辑/etc/security/limits.conf，添加两行：

    * soft core unlimited
    * hard core unlimited
    

    重启系统后生效
• 找到core文件：默认生成在OpenSips的工作目录，或者/var/crash目录下，文件名格式为core.<进程PID>
• 用GDB分析：执行gdb /usr/sbin/opensips core.14090（替换成你的core文件名），输入bt命令查看调用栈，就能直接定位到导致段错误的代码行或模块。

2. 检查OpenSips配置与模块 #

• 回顾配置变更：如果是最近修改了配置后才出现崩溃，重点检查路由脚本、模块参数是否有内存泄漏、非法指针引用这类问题。
• 排查第三方模块：非官方或自定义模块是段错误的高发区，尝试禁用可疑模块，重启服务后观察是否还会崩溃。
• 开启详细日志：把OpenSips配置里的debug_level调到3或更高，记录更多运行细节——崩溃前的日志往往能帮你找到触发问题的具体请求或操作。

3. 系统层面排查 #

• 内存状态：用free -h、vmstat检查系统内存是否耗尽，swap是否频繁使用，内存不足也可能间接导致进程崩溃。
• 系统日志：查看/var/log/syslog，看看崩溃前后是否有内核报错、磁盘IO异常这类系统级问题。
• 版本兼容性：确认你用的OpenSips版本和Ubuntu系统版本是否兼容，建议升级到最新稳定版，很多已知bug都会在新版本中修复。

完全不需要急着换成CentOS或Debian。段错误本质是代码层面（OpenSips本身或加载的模块）的内存访问错误，和发行版关系极小。除非你排查后确认是Ubuntu特有的内核依赖或库版本问题，否则优先聚焦OpenSips本身的问题。真到那一步再考虑换系统也不迟。

内容的提问来源于stack exchange，提问作者Kamal Panhwar