observer 进程异常退出

更新时间：2026-06-14 19:19:35

问题排查思路

当正在运行的 OBServer 异常退出时，您通过操作系统（例如 ps -ef 命令）查询不到 observer 进程的存在。此时，如果不是硬件损坏或者操作系统的问题，可尝试拉起 observer 进程作为应急手段。

OBServer 在退出时会生成 core dump 文件，该文件通常比较大，可达几十 GB 甚至上百 GB，可以此为依据进行 OBServer 的异常退出根因分析。通常情况下，OBServer 可能是由于 signal 11（无效内存访问)、signal 6（进程放弃）等异常原因退出。因此在进行问题排查时一般考虑是由于 OBServer 本身的问题，或者操作系统或者底层的原因。

问题排查方法

在分析 OBServer 异常退出产生 core dump 问题的根因时，根据当前版本不同，排查的方法稍有差别，具体如下：

V1.x 以及 V2.2.30 BP16 之前的版本

需要直接调试 core dump 文件进行根因分析。
V2.2.30 BP16 及以上版本，V2.2.7x ，V3.x 及以上的版本

可直接分析 observer.log 。因为这些版本对诊断功能进行了增强。对于异常退出的场景，会直接在 observer.log 中打印携带 CRASH ERROR!!! 关键字的 call stack（也称 backtrace）的信息，这些信息里包含了 OBServer 异常退出的直接原因和问题现场。具体信息如下：
```
CRASH ERROR!!! sig=11, sig_code=1, sig_addr=0x42, tid=27311, tname=test_context,
trace_id=Y0-0000000000000000, extra_info=((null)), lbt=0x58b9f0 0x58c00f 0x7fcb153fe61f
0x4a1342 0x9fc8fb 0x9f66f5 0x9dc80e 0x9dd097 0x9dd727 0x9e3fdf 0x9fdcd9 0x9f74eb 0x9e2c1b
0x4abcc0 0x4a801b 0x7fcb144b6444 0x4a1028 Segmentation fault (core dumped)
```

问题排查步骤

对于 observer 退出的根因，如果您无法判断为已知问题并可自行修复，需要您获取相关信息给到 OceanBase 技术支持人员进行根因分析。若因 core 文件过大或者生产环境无法及时将文件传给相关人员，请先在问题现场对异常退出的 observer 进行初步诊断，其中最重要的是获取 OBServer 异常退出时的直接原因及退出线程的线程栈信息。

请您根据当前版本情况按照如下步骤进行分析。

V2.2.76 版本以前
1. 您需要从 OceanBase 技术支持人员处获取 OBServer 的 debuginfo rpm 包，在安装或者解压后才可以将 observer 线程的 call stack 信息解析成可读的方法名，或者调试 core 文件。需注意，需要解压与 OBServer 版本相对应的版本。具体操作如下：
```
rpm2cpio oceanbase-debuginfo-xxx.el7.x86_64.rpm | cpio -div
```
2. 将解压出的 observer.debug 文件拷贝进 observer 目录，默认为 /home/admin/oceanbase/bin 目录。
3. 调试 core 文件。具体命令如下：
```
gdb $observer $core_file  -ex bt
```
  示例如下：
```
gdb /home/admin/oceanbase/bin/observer core-observer-113058-1614065734 -ex bt
```
  注意
  
  这里是在调试 core 文件，如果直接调试运行中的 observer, 会影响系统的可用性。如果对 GDB 其他的各种功能感兴趣，请在测试环境进行验证。
  
  输出结果的关键信息如下图所示。
```
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/home/admin/oceanbase/bin/observer'
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f0798a354eb in raise ( from /lib64/libpthread.so.0
[Current thread is 1 (Thread 0x7F0430228700 (LWP 113058))]
#0  0x000070798a354eb in raise () from /lib64/libpthread.so.0
#1  0x000000000915878 in oceanbase:: common:: coredump_cb(int, siginfo_t*) ()
#2  <signal handler called>
#3  0x000070798204e9d in nanosleep () from /lib64/libc.so.6
#4  0x000070798204d34 in sleep () from /lib64/libc.so.6
#5  0x0000000009130d9 in oceanbase:: observer:: ObServer:: wait() ()
#6  0x000000000317 da82 in main()
```
4. 获取到关键信息后，可在交互页面输入 quit 命令退出 GDB，也可选用 -batch 选项进入非交互模式将输出直接重定向到一个文件，更多 GDB 的用法，请参见 GDB 文档。
V2.2.76 版本之后

通过 OBServer 的可执行文件获取线程栈的 call stack 信息，或者调试 core 文件。如果 observer.log 里在进程退出时生成了 CRASH ERROR!!! 关键字，记录了 observer 线程异常退出的 call stack 重要信息（'lbt=' 关键字后尾随的地址 hex 值），执行以下命令获取线程信息。
```
addr2line -pCfe $observer $symbol_addr
```
示例如下：
```
addr2line -pCfe /home/admin/oceanbase/bin/observer 0x58b9f0 0x58c00f 0x7fcb153fe61f 0x4a1342 0x9fc8fb 0x9f66f5 0x9dc80e 0x9dd097 0x9dd727 0x9e3fdf 0x9fdcd9 0x9f74eb 0x9e2c1b 0x4abcc0 0x4a801b 0x7fcb144b6444 0x4a1028
```
这里的信息包含 CRASH ERROR!!! 原始信息和打印的线程栈信息。

收集完以上信息后，请将包含进程退出的直接原因（signal 信息）、线程栈信息和 OBServer 的版本信息发送给 OceanBase 技术支持人员。