--- title: "observer 进程异常退出 | OceanBase 文档中心" description: observer 进程异常退出 问题排查思路 当正在运行的 OBServer 异常退出时，您通过操作系统（例如 ps -ef 命令）查询不到 observer 进程的存在。此时，如果不是硬件损坏或者操作系统的问题，可尝试拉起 observer 进程作为应急手段。 OBServer 在退出时会生成 core dump … --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*P8CuR4UJ_FkAAAAAAAAAAAAADiGDAQ/original) OceanBase 数据库分布式版 - V 3.2.4 企业版 LTS # 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 异常退出的直接原因和问题现场。具体信息如下： ```shell 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 异常退出时的直接原因及退出线程的线程栈信息。 请您根据当前版本情况按照如下步骤进行分析。 1. V2.2.76 版本以前 1. 您需要从 OceanBase 技术支持人员处获取 OBServer 的 debuginfo rpm 包，在安装或者解压后才可以将 observer 线程的 call stack 信息解析成可读的方法名，或者调试 core 文件。需注意，需要解压与 OBServer 版本相对应的版本。具体操作如下： ```shell rpm2cpio oceanbase-debuginfo-xxx.el7.x86_64.rpm | cpio -div ``` 2. 将解压出的 observer.debug 文件拷贝进 observer 目录，默认为 `/home/admin/oceanbase/bin` 目录。 3. 调试 core 文件。具体命令如下： ```shell gdb $observer $core_file -ex bt ``` 示例如下： ```unknow gdb /home/admin/oceanbase/bin/observer core-observer-113058-1614065734 -ex bt ``` > **注意** > > > > 这里是在调试 core 文件，如果直接调试运行中的 observer, 会影响系统的可用性。如果对 GDB 其他的各种功能感兴趣，请在测试环境进行验证。 输出结果的关键信息如下图所示。 ```shell [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 #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](https://sourceware.org/gdb/current/onlinedocs/gdb/) 文档。 2. V2.2.76 版本之后 通过 OBServer 的可执行文件获取线程栈的 call stack 信息，或者调试 core 文件。如果 observer.log 里在进程退出时生成了 `CRASH ERROR!!!` 关键字，记录了 observer 线程异常退出的 call stack 重要信息 （`'lbt='` 关键字后尾随的地址 hex 值），执行以下命令获取线程信息。 ```shell addr2line -pCfe $observer $symbol_addr ``` 示例如下： ```shell 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 技术支持人员。 上一篇 下一篇 ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线