收集的信息或报告将上传到错误跟踪系统。
如果系统中的任何进程因为常见的信号而死机（如分段错误、总线错误、浮点异常等），或者例如打包的Python应用程序引发了未捕获的异常，apport后端会自动调用。
它会在/var/crash/目录下生成一个初始的崩溃报告文件（文件名由崩溃的可执行文件名和用户ID组成）。如果崩溃的进程属于当前登录的用户，或者它属于系统进程并且用户是管理员，apport会通知用户有关崩溃的情况，并提供报告问题的选项。
如果用户保持“发送错误报告”复选框启用状态，Apport会将收集到的信息上传到错误跟踪系统。之后，它会打开软件包的错误提交页面，并提供一个合理的默认错误标题，然后将其余的错误提交过程交给Web界面处理。
Ubuntu每天通过我们的错误跟踪系统收到大量的错误报告。每一个错误报告都需要被阅读、评估和分类，以便进行修复。这就是我们需要您协助处理错误的地方。如果想要了解错误分类过程的视觉表示，请参考这些漂亮的流程图。
每个错误报告都是与报告者的对话。报告者通常与Ubuntu社区的错误分类人员首次接触，后者试图整理出完整的错误报告。给出良好的印象非常重要，所以请礼貌并尽量使用您最好的英语。
处理简单的未分类错误是入门并熟悉错误分类程序的好方法，因为您将需要处理错误的整个生命周期的各个方面。未分类错误部分解释了如何找到它们。
错误类型
Apport报告
Apport报告是通过自动错误报告程序Apport报告的错误。使用Apport报告错误是报告错误的首选方式，因为它为开发人员提供了有关受影响系统的大量信息。当使用Apport时，需要的额外信息较少，从而加快整个过程的速度。
你可以通过描述中附加的系统信息列表来识别这些错误。一些程序在报告错误时会添加Apport的钩子，以提供更多信息。这些信息通常可以在附件中找到。
已确认的错误
当一个错误被标记为“已确认”时，它还没有完全进行分类。这个错误非常接近被标记为“已分类”，但你需要确保它已经准备好供开发人员修复。
功能请求
如果错误报告实际上是一个功能请求，有两种可能性。如果所请求的增强功能很小且明确定义，或者建议涉及上游项目，则应将错误的重要性设置为“愿望清单”。当报告完成后，状态应设置为“已分类”。
只有Ubuntu Bug Control团队的成员才能这样做。如果你不是成员，你必须请教一个成员来帮你做。将错误编号粘贴到#ubuntu-bugs频道，并说明你认为该错误应该被设置为“愿望清单”。有人会注意到并为你设置，尽管不一定会立即生效。
内部工作原理是什么？
崩溃拦截
Apport 使用 /proc/sys/kernel/core_pattern 将核心转储直接导入到 apport 中：
$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c
$
请注意，即使将ulimit设置为禁用核心文件（通过使用ulimit -c 0指定核心文件大小为零），apport仍然会捕获崩溃。
为了拦截Python崩溃，它会安装一个/etc/python*/sitecustomize.py来在未处理的异常上调用apport。
示例：
即使PID 1（Upstart）死亡，Apport甚至也能够捕获核心文件。
- 如果Upstart检测到内部不一致，它会引发SIGABRT信号。
- 在SIGABRT上调用Upstart崩溃处理程序。
- Upstart崩溃处理程序fork一个子进程。
- Upstart子进程重新引发信号，导致子进程异常退出。
- 内核检测到子进程异常退出，并调用apport，将核心文件通过apport的标准输入管道传输（由于/proc/sys/kernel/core_pattern）。
- apport将核心文件写入磁盘中的/var/crash/。
- PID 1等待其子进程终止（这只有在apport完成写入核心文件后才会发生）。
- PID 1退出。
- 内核发生panic。
- 下次启动时，Whoopsie将检测崩溃文件并处理。
后端
为了尽可能减少延迟和CPU/IO的影响，
/usr/share/apport/apport只收集在崩溃进程仍然存在时需要获取的数据：来自
/proc/pid的信息、核心转储、可执行路径和信号编号。报告将被写入
/var/crash/executable_path.uid.crash。
前端调用
在Gnome中，update-notifier对
/var/crash进行inotify监视。每当有新内容时，它会调用 /usr/share/apport/apport-checkreports。如果有新的报告，它会调用/usr/share/apport/apport-gtk，这是上面截图中显示的前端界面。
然后，前端会收集其他信息，如软件包版本、软件包文件校验和操作系统版本，并调用所有匹配的软件包钩子。
要禁用此功能，您可以运行gsettings set com.ubuntu.update-notifier show-apport-crashes false（作为普通桌面用户）。
基于Launchpad的自动重新跟踪程序
规范数据中心运行一个自动使用apport追踪错误的服务。通过在Launchpad上按照架构标记错误，将进行追踪并移除标记。使用的标记有need-i386-retrace或need-amd64-retrace。请参阅公告。
每个软件包都可以指定从系统中收集的信息，并包含在错误报告中。这些信息是由软件包中的apport hooks完成的。一些有用的示例包括：
- source_xorg.py - 将附加的日志文件和硬件详细信息添加到错误报告中
- usplash - 忽略特定代码路径中的崩溃
- source_totem.py - 向报告者提问，并根据回答收集不同的信息
这些hooks位于/usr/share/apport/package-hooks目录中。还有一个提供apport hooks的软件包列表。
如果通过apport提交了崩溃或错误报告，相关的hooks将自动运行。如果您有一个已经报告但没有使用apport提交的bug，并且您对这些hooks中的信息感兴趣，您可以要求报告者使用apport-collect bugnumber命令。
使用源代码，卢克！
- 你可以从Launchpad项目页面下载上游tarball，或者从Ubuntu存档中下载Ubuntu源码tarball。
- apport是使用Launchpad上的bazaar RCS开发的。如果你想为其做贡献或者基于它开发自己的系统，你可以通过bzr get lp:apport获取自己的分支（用于主干），或者通过debcheckout -a apport获取Ubuntu打包分支。
未来计划
将进行各种性能改进，提供更好的报告处理工具，并集成更多语言（Mono/Python堆栈跟踪、断言消息等）。请参阅相关规范。
来源：Apport，如何进行分类处理和如何启用Apport
