企业官网建设流程全解析

CentOS7生产环境突发中断？别慌，先检查abrt-hook-ccpp这个‘守护者’

当生产环境的服务器突然中断服务，那种感觉就像半夜被电话惊醒——心跳加速、手心冒汗。作为运维人员，我们最怕的就是这种毫无征兆的故障。最近遇到一个典型案例：一台运行CentOS7的服务器上，关键分析流程msisensor2突然崩溃，查看日志只看到几条来自abrt-hook-ccpp的神秘记录。这到底是怎么回事？让我们揭开这个"系统守护者"的面纱。

1. 认识abrt-hook-ccpp：系统里的"热心保安"

abrt（Automatic Bug Reporting Tool）是Linux系统中的一个自动化错误报告工具，而abrt-hook-ccpp则是它的一个重要组件。你可以把它想象成大楼里的保安——本意是好的，但有时候可能过于尽职。

这个"保安"的主要职责是：

• 监控系统中的程序崩溃事件
• 收集崩溃时的核心转储(core dump)和相关信息
• 为后续的问题分析保留现场证据

但当它遇到以下情况时，可能会引发问题：

• 非RPM安装的自编译程序（如msisensor2）
• 容器内运行的应用
• 资源消耗较大的Java/.NET应用

典型的症状包括：

1. 进程突然被终止，日志中出现"SIGABRT"信号
2. 在/var/spool/abrt/目录下生成问题目录后又立即被删除
3. 服务中断但缺乏有效的排查线索

2. 故障诊断：解读abrt的"行为模式"

当abrt-hook-ccpp介入时，系统日志通常会留下这样的事件链：

abrt-hook-ccpp: Process 243912 (msisensor2) of user 1000 killed by SIGABRT - dumping core abrt-server: Executable '/data/ngs/softs/msisensor2/msisensor2' doesn't belong to any package abrt-server: 'post-create' exited with 1 abrt-server: Deleting problem directory

这四行日志揭示了完整的事件流程：

1. 捕获阶段：abrt检测到msisensor2进程收到SIGABRT信号
2. 验证阶段：发现该程序不是通过RPM安装的
3. 处理阶段：尝试创建问题报告但失败（退出码1）
4. 清理阶段：删除临时生成的问题目录

关键配置参数解析：

3. 解决方案：与"保安"达成共识

根据不同的生产环境需求，我们有三种方式与这个"热心保安"相处：

3.1 方案一：扩大保安的职责范围（推荐）

修改配置，让abrt也监控非RPM安装的程序：

# 编辑配置文件 vim /etc/abrt/abrt-action-save-package-data.conf # 将ProcessUnpackaged改为yes ProcessUnpackaged = yes # 重启服务 systemctl restart abrtd

适用场景：

• 需要保留崩溃现场进行分析
• 系统中有多个自编译程序
• 磁盘空间充足

优点：

• 保留完整的故障信息
• 不影响程序正常运行
• 便于后续问题排查

缺点：

• 可能收集到不必要的崩溃数据
• 需要定期清理/var/spool/abrt/目录

3.2 方案二：调整保安的工作标准

放宽对核心转储文件大小的限制：

# 编辑主配置文件 vim /etc/abrt/abrt.conf # 取消大小限制 MaxCrashReportsSize = 0 # 可选：调整保存的报告数量 MaxCrashReports = 5 # 重启服务 systemctl restart abrtd

注意事项：

在资源紧张的环境中，建议设置合理的MaxCrashReportsSize值（如2048），而不是完全禁用限制

3.3 方案三：临时调离岗位（慎用）

完全禁用abrt-ccpp服务：

# 停止并禁用服务 systemctl stop abrt-ccpp.service systemctl disable abrt-ccpp.service # 同时停止abrtd服务（可选） systemctl stop abrtd.service

风险提示：

• 将无法获取任何程序的崩溃信息
• 可能掩盖更深层次的系统问题
• 不推荐在生产环境长期使用

4. 深度优化：构建更智能的监控体系

单纯的开启或关闭abrt服务都不是最佳方案。对于关键生产环境，建议建立更完善的监控策略：

4.1 资源监控与预警

使用以下工具组合监控系统资源：

# 安装基础监控工具 yum install -y sysstat glances # 查看实时资源使用 glances

建议监控以下关键指标：

• CPU使用率（特别是单核饱和）
• 内存使用（包括swap）
• 磁盘I/O等待
• 系统负载平均值

4.2 自定义abrt处理流程

高级用户可以配置abrt的插件系统，实现：

1. 自定义崩溃报告的存储位置
2. 添加邮件通知功能
3. 与外部错误跟踪系统集成

示例配置：

# 创建自定义处理脚本 vim /etc/abrt/plugins/my_action.conf [Plugin] Event = post-create Executable = /usr/local/bin/my_custom_handler

4.3 替代方案：使用coredumpctl

对于使用systemd的系统，可以考虑：

# 启用systemd-coredump vim /etc/systemd/coredump.conf [Journal] Storage=external Compress=yes # 查看捕获的核心转储 coredumpctl list

对比abrt与coredumpctl：

5. 实战案例：一次完整的故障排查过程

最近处理的一个真实案例：某生物信息分析平台的msisensor2进程频繁崩溃。

排查步骤：

1. 检查系统日志，发现abrt干预痕迹
2. 确认msisensor2是源码编译安装
3. 检查abrt配置，发现ProcessUnpackaged=no
4. 临时设置ProcessUnpackaged=yes复现问题
5. 分析生成的核心转储文件：

gdb /data/ngs/softs/msisensor2/msisensor2 /var/spool/abrt/ccpp-xxxxxx/coredump bt full

6. 发现是内存不足导致的堆栈溢出
7. 解决方案：
   • 优化程序内存使用
   • 增加服务器内存
   • 调整abrt配置保留崩溃现场

经验总结：

• 不要急于禁用abrt，它可能是发现深层问题的窗口
• 核心转储文件是宝贵的调试资源
• 在测试环境模拟生产配置可以预防问题