Domino服务器启动崩溃求助：SLES 11 SP4环境下报0x0000000b错误

我之前处理过类似的Domino服务器因系统补丁更新导致崩溃的案例，结合你的环境（SLES 11 SP4 + Domino 8.5.1FP5）和报错信息Fatal Error signal = 0x0000000b PID/TID = 6944/-184699184，给你几个针对性的排查和修复方向：

先解析报错含义 #

0x0000000b对应Linux的SIGBUS（总线错误），通常是程序访问了不存在的内存地址，或者依赖的系统库版本不兼容导致的——这和你安装安全补丁后出现问题的时间线完全吻合，大概率是补丁更新了Domino依赖的核心系统库。

具体排查步骤 #

1. 检查Domino依赖的系统库版本变化 #

Domino 8.5.1FP5是比较老的版本，对系统库的版本有严格要求。你可以用以下命令查看服务器二进制文件的依赖库：

ldd /opt/ibm/domino/bin/server

重点关注glibc、libpthread、libstdc++这些核心库的版本，对比同版本未打安全补丁的SLES11 SP4机器的库版本，或者你之前的系统备份（如果有的话）。如果发现某个库版本在补丁后明显更新，那很可能就是冲突源。

2. 回滚近期安装的安全补丁 #

虽然你不确定具体是哪个补丁，但可以通过SLES的包管理工具列出最近的更新记录：

zypper list-updates --history | grep -i security

按时间倒序查看安全补丁，从最近的几个开始逐个回滚测试（回滚命令：zypper remove <补丁名称>），每回滚一个就重启机器，再尝试启动Domino，直到找到导致崩溃的补丁。注意部分补丁可能有依赖关系，需要一起回滚。

3. 生成并分析核心转储文件 #

启用系统的core dump功能，能帮你精准定位崩溃的代码模块：

1. 先设置允许生成core文件：

   ulimit -c unlimited
   

2. 启动Domino服务器，等待崩溃后，当前目录会生成一个core.<PID>的文件。
3. 用gdb分析核心转储：

   gdb /opt/ibm/domino/bin/server core.<PID>
   

4. 在gdb提示符下输入bt查看调用栈，这会显示崩溃发生时的函数调用链，直接指向冲突的库或Domino模块，帮你快速缩小排查范围。

4. 验证Domino与SLES的兼容性 #

虽然Domino 8.5.1FP5官方支持SLES11 SP4，但安全补丁可能打破了这种兼容性。你可以查阅IBM官方的Domino 8.5.x兼容性文档，确认是否有已知的系统库版本限制，或者是否有针对SLES11安全补丁的Domino hotfix。

5. 临时 workaround：替换兼容的系统库 #

如果确认是某个库版本不兼容，可以从一台未打补丁的同版本SLES11 SP4机器上复制对应的库文件，放到Domino的bin目录下（比如新建一个custom_lib子目录），然后设置环境变量优先加载这个目录的库：

export LD_LIBRARY_PATH=/opt/ibm/domino/bin/custom_lib:$LD_LIBRARY_PATH
/opt/ibm/domino/bin/server

这是临时解决办法，长期来看还是需要找到兼容的补丁组合，或者升级Domino到更高版本（如果业务允许的话）。

补充说明 #

你已经尝试过切换运行级别2（排除桌面环境干扰）和重装Fixpack5（排除Domino文件损坏），所以问题基本可以锁定在系统层面的库或补丁冲突上，按照上面的步骤排查应该能找到根源。

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