用 coredumpctl 更好地记录 bug
coredump 调试
![](/data/attachment/album/201711/28/230423v9yp293hhfafy0vf.jpg)


一个不幸的事实是，所有的软件都有 bug，一些 bug 会导致系统崩溃。当它出现的时候，它经常会在磁盘上留下一个被称为“<ruby> 核心转储 <rt>  core dump </rt></ruby>”的数据文件。该文件包含有关系统崩溃时的相关数据，可能有助于确定发生崩溃的原因。通常开发者要求提供 “<ruby> 回溯 <rt>  backtrace </rt></ruby>” 形式的数据，以显示导致崩溃的指令流。开发人员可以使用它来修复 bug 以改进系统。如果系统发生了崩溃，以下是如何轻松生成 <ruby> 回溯 <rt>  backtrace </rt></ruby> 的方法。


### 从使用 coredumpctl 开始


大多数 Fedora 系统使用[自动错误报告工具（ABRT）](https://github.com/abrt/abrt)来自动捕获崩溃文件并记录 bug。但是，如果你禁用了此服务或删除了该软件包，则此方法可能会有所帮助。


如果你遇到系统崩溃，请首先确保你运行的是最新的软件。更新通常包含修复程序，这些更新通常含有已经发现的会导致严重错误和崩溃的错误的修复。当你更新后，请尝试重现导致错误的情况。


如果崩溃仍然发生，或者你已经在运行最新的软件，那么可以使用有用的 `coredumpctl` 工具。此程序可帮助查找和处理崩溃。要查看系统上所有核心转储列表，请运行以下命令：



```
coredumpctl list

```

如果你看到比预期长的列表，请不要感到惊讶。有时系统组件在后台默默地崩溃，并自行恢复。快速查找今天的转储的简单方法是使用 `-since` 选项：



```
coredumpctl list --since=today

```

“PID” 列包含用于标识转储的进程 ID。请注意这个数字，因为你会之后再用到它。或者，如果你不想记住它，使用下面的命令将它赋值给一个变量：



```
MYPID=<PID>

```

要查看关于核心转储的信息，请使用此命令（使用 `$MYPID` 变量或替换 PID 编号）：



```
coredumpctl info $MYPID

```

### 安装 debuginfo 包


在核心转储中的数据以及原始代码中的指令之间调试符号转义。这个符号数据可能相当大。与大多数用户运行在 Fedora 系统上的软件包不同，符号以 “debuginfo” 软件包的形式安装。要确定你必须安装哪些 debuginfo 包，请先运行以下命令：



```
coredumpctl gdb $MYPID

```

这可能会在屏幕上显示大量信息。最后一行可能会告诉你使用 `dnf` 安装更多的 debuginfo 软件包。[用 sudo](https://fedoramagazine.org/howto-use-sudo/) 运行该命令以安装：



```
sudo dnf debuginfo-install <packages...>

```

然后再次尝试 `coredumpctl gdb $MYPID` 命令。**你可能需要重复执行此操作**，因为其他符号会在回溯中展开。


### 捕获回溯


在调试器中运行以下命令以记录信息：



```
set logging file mybacktrace.txt
set logging on

```

你可能会发现关闭分页有帮助。对于长的回溯，这可以节省时间。



```
set pagination off

```

现在运行回溯：



```
thread apply all bt full

```

现在你可以输入 `quit` 来退出调试器。`mybacktrace.txt` 包含可附加到 bug 或问题的追踪信息。或者，如果你正在与某人实时合作，则可以将文本上传到 pastebin。无论哪种方式，你现在可以向开发人员提供更多的帮助来解决问题。




---


作者简介：


Paul W. Frields


Paul W. Frields 自 1997 年以来一直是 Linux 用户和爱好者，并于 2003 年在 Fedora 发布不久后加入 Fedora。他是 Fedora 项目委员会的创始成员之一，从事文档、网站发布、宣传、工具链开发和维护软件。他于 2008 年 2 月至 2010 年 7 月加入 Red Hat，担任 Fedora 项目负责人，现任红帽公司工程部经理。他目前和妻子和两个孩子住在弗吉尼亚州。




---


via: <https://fedoramagazine.org/file-better-bugs-coredumpctl/>


作者：[Paul W. Frields](https://fedoramagazine.org/author/pfrields/) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
An unfortunate fact of life is that all software has bugs, and some bugs can make the system crash. When it does, it often leaves a data file called a *core dump* on disk. This file contains data about your system when it crashed, and may help determine why the crash occurred. Often developers request data in the form of a *backtrace*, showing the flow of instructions that led to the crash. The developer can use it to fix the bug and improve the system. Here’s how to easily generate a backtrace if you have a system crash.


## Getting started with coredumpctl

Most Fedora systems use the [Automatic Bug Reporting Tool (ABRT)](https://github.com/abrt/abrt) to automatically capture dumps and file bugs for crashes. However, if you have disabled this service or removed the package, this method may be helpful.

If you experience a system crash, first ensure that you’re running the latest updated software. Updates often contain fixes that have already been found to fix a bug that causes critical errors and crashes. Once you update, try to recreate the situation that led to the bug.

If the crash still happens, or if you’re already running the latest software, it’s time to use the helpful *coredumpctl* utility. This utility helps locate and process crashes. To see a list of all core dumps on your system, run this command:

coredumpctl list

Don’t be surprised if you see a longer list than expected. Sometimes system components crash silently behind the scenes, and recover on their own. An easy way to quickly find a dump from today is to use the *–since* option:

coredumpctl list --since=today

The *PID* column contains the process ID used to identify the dump. Note that number, since you’ll use it again along the way. Or, if you don’t want to remember it, assign it to a variable you can use in the rest of the commands below:

MYPID=<PID>

To see information about the core dump, use this command (either use the *$MYPID* variable, or substitute the PID number):

coredumpctl info $MYPID

## Install debuginfo packages

Debugging symbols translate between data in the core dump and the instructions found in original source code. This symbol data can be quite large. Therefore, symbols are shipped in *debuginfo* packages separately from the packages most users run on Fedora systems. To determine which debuginfo packages you must install, start by running this command:

coredumpctl gdb $MYPID

This may result in a large amount of information to the screen. The last line may tell you to use *dnf* to install more debuginfo packages. Run that command [with sudo](https://fedoramagazine.org/howto-use-sudo/) to continue:

sudo dnf debuginfo-install<packages...>

Then try the *coredumpctl gdb $MYPID* command again. **You may need to do this repeatedly,** as other symbols are unwound in the trace.

## Capturing the backtrace

Run the following commands to log information in the debugger:

set logging file mybacktrace.txt set logging on

You may find it helpful to turn off the pagination. For long backtraces this saves time.

set pagination off

Now run the backtrace:

thread apply all bt full

Now you can type *quit* to quit the debugger. The *mybacktrace.txt* file includes backtrace information you can attach to a bug or issue. Or if you’re working with someone in real time, you can upload the text to a pastebin. Either way, you can now provide more assistance to the developer to fix the problem.

## ifoolb

Sometimes the system is completely unresponsive, even sysrq doesn’t work, while the display is still on. Any way to generate crash dump in such situations(especially on a laptop, no firewire, serial ports )?

## wk3

There is. Use the Magic SysRq key!

When the system has become useless,

andyou cannot create nor resume an alternate console session (Ctrl+Alt+F2, Ctrl+Alt+F3, etc.), press the keystroke sequence to cause a system crash:Alt + SysRq c

See https://en.wikipedia.org/wiki/Magic_SysRq_key for all the commands available for the Magic SysRq key.

By the way, if you can switch to an alternate console session, list the highest CPU usage processes with “top”. In Fedora 24 and 25, it has almost always been (for me) caused by gnome-shell. A system hang can perhaps be cleared up by killing it (and for gnome-shell, letting it self restart). Then switch back to GUI mode (with Ctrl+Alt+F1) and see if the problem clears up.

If you run “top” as root (use “su” to get the # prompt), “top” has a command to kill processes. When the offending process is at the top of the list, press “k” and it will prompt with

PID to signal/kill [default pid = 23123]

If it is correct, press Enter; otherwise type in the pid of the suspected errant process then Enter. “Top” prompts with

Send pid 23123 signal [15/sigterm]

Many processes will exit cleanly with SIGTERM, so just press Enter. If that doesn’t kill it, I find that signal 9 (SIGKILL) will do the job (programs cannot ignore or catch SIGKILL). See “man 7 signal” for details.

## Leslie Satenstein

Very informative article. Because Fedora is so stable, I do not see many crashes or aborts. Hence, this software is something I would not come across in daily use. It’s good to know for any future situation.

Thank you.