龙叔Linux:abrt-hook-ccpp

1、什么是abrt-hook-ccpp

abrt也可以叫abrtd,展开应该是automatically bug report daemon,也就是自动错误报告守护进程。
从字面意义就可以看出,他是一个守护进程,监控进程,如果进程出现崩溃,那么他就会开始工作,收集bug,收集现场。用于在发生崩溃时报告软件包中的错误

2、abrt配置文件解析

2.1、配置文件abrt.conf

配置文件完整路径:
/etc/abrt/abrt.conf

a、MaxCrashReportsSize
控制dump的最大size,如果程序崩溃也不产生dump文件,那可以试试将这个配置项改为0,无限制

b、DumpLocation
存放dump文件的目录,默认是/var/spool/abrt,当abrt工作时,会创建对应的dump文件目录

c、WatchCrashdumpArchiveDir
如果你想让abrtd自动解包出现在这个目录下的crashdump 包,启用此选项,并制定这个目录,默认是/var/spool/abrt-upload

d、DeleteUploaded
如果想要自动清除上传目录,必须调整selinux策略,默认是no

e、AutoreportingEvent
配置的是事件的名称,在检测到问题后自动运行这个事件。该事件应该执行一些快速分析,如果知道问题,则将以70退出。默认是report_uReport,并且如果想启用这个,AutoreportingEnabled需要配置为yes

f、AutoreportingEnabled
启用自动运行在AutoreportingEvent选项中配置的事件。默认为no

g、ShortenedReporting
在AutoreportingEvent完成后,启用缩短的GUI报告,默认为yes

h、PrivateReports
默认值为yes,如果你想允许普通用户有文件系统权限读取存储在DumpLocation的问题数据。那就设置为no。
问题数据包含/var/log/messages, dmesg和sosreport数据的摘要,由abrtd生成在用户根下。

i、DebugLevel
允许ABRT工具检测ABRT本身的问题。通过增加该值,可以强制ABRT检测、处理和报告ABRT中的问题。但是,在处理自身引起的问题时,ABRT可能会陷入无限循环。默认值是0(non debug mode)

2.2、配置文件abrt-action-save-package-data.conf

配置文件完整路径:
/etc/abrt/abrt-action-save-package-data.conf

a、OpenGPGCheck
只分析签名包中的崩溃,默认为yes

b、BlackList
列入黑名单的包,默认值是“nspluginwrapper, valgrind, strace, mono-core“

c、ProcessUnpackaged
处理不属于任何包的可执行文件中的崩溃?默认是no,有时候有些进程崩溃但是没有产生dump文件,可以把这个改成yes再试试。

d、BlackListedPaths
可执行路径黑名单(shell模式)
默认值是“/usr/share/doc/, /example, /usr/bin/nspluginviewer, /usr/lib/xulrunner-/plugin-container”

e、Interpreters
编译器,默认值是“python2, python2.7, python, python3, python3.3, perl, perl5.16.”

3、问题案例分享

3.1、问题现象

服务器出现两个告警
a、根目录磁盘空间告警
b、服务器内存使用率告警

在这里插入图片描述

3.2、问题定位

a、内存问题定位:
top命令 发现有三个abrt-hook-ccpp进程消耗资源非常大
在这里插入图片描述
b、根目录磁盘空间使用率问题定位:
从根目录一路使用”du ./ --max-depth=1”,找到占用空间最大的目录是/var/spool/abrt
在这里插入图片描述

c、确定原因
于是可以看出不管是磁盘空间使用正常还是内存使用突增,都是和abrt-hook-ccpp有关系

在messages日志中可以搜索abrt关键字,可以看到是 三个 vim 进程奔溃导致拉起的abrt-hook-ccpp
在这里插入图片描述

而abrt-hook-ccpp产生的目录名后面的数字也正是对应崩溃程序的进程ID,搜索之后发现是vim进程
aaa

本次问题是有人使用vim查看日志文件,而文件过大,vim崩溃导致

3.3、问题处理

解决方法很简单,kill掉三个vim进程就可以了,kill掉之后,三个abrt-hook-ccpp进程也消失了,abrt-hook-ccpp产生的文件也消失了

不过为了避免再次发生这样的事情,可以关闭abrt-hook-ccpp

systemctl stop abrt-ccpp.service
systemctl disable abrt-ccpp.service
systemctl status abrt-ccpp.service

-----------------------本文完

欢迎关注我的公众号:龙叔运维
持续分享运维经验

<think>好的,我现在遇到了一个ABRT报错的问题,提示“ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1741944599”。我需要先弄清楚ABRT是什么,然后理解这个错误的具体含义以及如何解决它。 首先,ABRT是Automatic Bug Reporting Tool的缩写,常见于Fedora、RHEL等Linux发行版中。它用于自动捕获和处理程序崩溃的报告。当系统中有应用程序崩溃时,ABRT会自动收集相关的诊断信息,帮助用户或开发者分析和解决问题。因此,这个提示意味着系统检测到了一个程序崩溃的问题,可能是某个应用程序或服务异常终止导致的。 接下来,我需要按照提示运行`abrt-cli list --since 1741944999`来获取更多信息。不过,用户给出的时间戳是1741944599,我需要确认是否正确。时间戳通常是从1970年1月1日开始的秒数,所以可以转换一下这个时间戳对应的具体时间,以确认问题发生的时间。例如,使用`date -d @1741944599`命令可以将时间戳转换为可读的日期和时间,帮助定位问题发生的时间点。 运行`abrt-cli list`命令后,系统会列出所有在指定时间之后检测到的问题。每个问题条目可能会包含崩溃的程序名称、时间、原因(如段错误、断言失败等)以及相关的日志文件路径。查看这些信息可以帮助确定是哪个应用程序出了问题,以及可能的原因。 例如,假设输出中显示某个程序(如firefox)发生了段错误(Segmentation Fault),那么可能是该程序本身存在bug,或者与系统库、依赖项不兼容有关。此时,可以检查是否有可用的更新,或者查看相关的日志文件获取更多线索。 此外,ABRT通常会保存崩溃报告的详细信息,包括核心转储(core dump)、日志文件等,这些文件通常位于`/var/spool/abrt/`目录下。用户可以查看这些文件以获取更详细的信息。但需要注意的是,处理核心转储可能需要一定的权限,可能需要使用`sudo`命令。 如果确定问题是由某个已知的软件bug引起的,可以检查系统更新,看看是否有相关的修复补丁。在Fedora中,可以使用`dnf update`来更新所有软件包。如果问题依然存在,可能需要向软件开发者或发行版维护者提交bug报告,附上ABRT收集的信息。 在某些情况下,如果问题不影响系统稳定性和使用,用户可以选择删除ABRT报告,释放磁盘空间。使用`abrt-cli remove <问题ID>`命令可以删除指定的问题报告。但建议在确认问题已解决或不需要进一步调查后再进行删除操作。 总结处理步骤: 1. 运行`abrt-cli list --since 1741944599`查看详细问题列表。 2. 根据输出确定崩溃的程序和原因。 3. 检查程序日志和核心转储文件,分析崩溃原因。 4. 更新相关软件或应用补丁。 5. 如无法解决,提交bug报告并提供ABRT收集的信息。 6. 清理已处理的问题报告。 需要确保用户理解每个步骤的作用,并在操作过程中谨慎处理系统文件和日志,避免误删重要信息。如果用户对命令行操作不熟悉,建议逐步指导命令的使用,或者建议寻求更专业的技术支持。</think>ABRT(Automatic Bug Reporting Tool)是Linux系统中用于自动捕获和分析程序崩溃的工具。当出现“ABRT has detected 1 problem(s)”提示时,说明系统检测到至少一个应用程序崩溃或错误。以下是逐步解决此问题的指南: --- ### **1. 查看详细错误信息** 运行命令获取崩溃报告列表: ```bash abrt-cli list --since 1741944599 ``` 这会列出指定时间戳(对应的时间为 **2025-02-12 12:09:59 UTC*)后检测到的问题。输出示例如下: ``` id 1741944600 原因: /usr/bin/firefox 段错误(Segmentation Fault) 时间: 2025-02-12 12:10:01 日志: /var/spool/abrt/ccpp-2025-02-12-12:10:01-1741944600 ``` --- ### **2. 分析具体崩溃原因** - **查看崩溃摘要**:记录输出中的`原因`字段(如段错误、断言失败等)。 - **检查日志文件**:进入日志目录(如`/var/spool/abrt/ccpp-...`),查看`backtrace`或`coredump`文件,定位崩溃时的调用栈。 ```bash cat /var/spool/abrt/ccpp-2025-02-12-12:10:01-1741944600/backtrace ``` --- ### **3. 常见解决方法** 根据崩溃原因选择以下操作: - **更新软件**:若崩溃由已知Bug引起,更新相关软件包。 ```bash sudo dnf update # Fedora/RHEL sudo apt update && sudo apt upgrade # Debian/Ubuntu ``` - **提交Bug报告**:使用ABRT自动提交(需配置): ```bash abrt-cli report <问题ID> ``` - **临时禁用ABRT**(不推荐):如需停止ABRT服务: ```bash sudo systemctl stop abrtd ``` --- ### **4. 清理已解决的问题** 若问题已修复,删除旧报告释放空间: ```bash abrt-cli remove <问题ID> # 删除单个报告 abrt-cli rm all # 删除所有报告 ``` --- ### **附:时间戳转换(验证问题时间)** 确认问题发生的时间: ```bash date -d @1741944599 ``` 输出示例: ``` Wed Feb 12 12:09:59 UTC 2025 ``` --- 通过以上步骤,可以定位崩溃程序、分析原因并采取修复措施。若需进一步帮助,请提供`abrt-cli list`的输出详情。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

龙叔运维

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值