“ ubuntu-bug”完成任务后会发生什么？

直到不久前，您才开始运行apport-bug或ubuntu-bug开始报告错误。然后，系统将使用您的帐户打开启动板，上传收集的信息，然后让您将更多信息添加到错误报告中。

现在，当我运行gksudo ubuntu-bug（例如，使用crash-file作为参数）时，将出现常见的错误对话框

就这样。

报告被发送到哪里？绝对不要将启动板作为错误报告（尽管在具体情况下，人们已经能够提交有关该错误的报告）。

所以：此报告发送到哪里（也许只是），我如何仍可以从系统中提交错误报告（使相关文件的上传更加容易）

可能是“系统”决定这将是一个已经存在的错误的副本吗？

从技术上讲，ubuntu-bug只需在本地记录崩溃报告。一个单独的程序会whoopsie监视记录的报告，并将其上载到中央数据库，在此将它们自动分组以识别总体问题。

结果数据显示在Ubuntu错误跟踪器上：

总体趋势是公开可用的，报告详细信息也可提供给受信任的开发人员。有关更多详细信息，请参见Ubuntu Wiki。

默认情况下，ubuntu-bug不会在稳定版本中打开Launchpad上的崩溃报告错误，但可以根据需要进行配置。进行更改后，您可以通过运行来打开现有崩溃报告的错误ubuntu-bug /var/crash/foo.crash。

收集的信息或报告将上传到错误跟踪系统。

如果系统中的任何进程由于通常称为“崩溃”（分段违规，总线错误，浮点异常等）的信号而死亡，或者例如打包的Python应用程序引发了未捕获的异常，则分配后端被自动调用。

它在/ var / crash /中的文件中生成初始崩溃报告（文件名由崩溃的可执行文件的名称和用户ID组成）。如果崩溃的进程属于当前登录的用户，或者属于系统进程，并且该用户是管理员，则apport会通知用户有关崩溃的信息，并提供报告问题的信息。

如果用户未启用“发送错误报告”复选框，则Apport会将收集到的信息上载到错误跟踪系统。之后，它会使用合理的默认错误标题打开软件包的错误提交页面，并将其余的错误提交过程留给Web UI。

Ubuntu每天都会通过我们的错误跟踪系统收到大量的错误报告。这些都需要阅读，评估和分类，以便可以解决。在这里，我们可以为您提供帮助以帮助解决错误。有关可视化的错误分类流程的信息，请参阅这些流程图。

每个错误报告都是与报告者的对话。任何记者通常与Ubuntu社区的首次联系都是通过错误分类程序进行的，错误分类程序试图将完整的错误报告汇总在一起。留下良好的印象非常重要，因此请保持礼貌并尝试使用最好的英语。

处理简单，未分类的错误是入门并熟悉分类程序的好方法，因为您必须处理错误生命周期的各个方面。未分类的错误部分说明了在何处找到它们。

错误类型

审批报告

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崩溃，它会安装a /etc/python*/sitecustomize.py来对未处理的异常调用apport。

例

如果PID 1（Upstart）死亡，Apport甚至可以捕获核心文件：

1. 如果Upstart检测到内部不一致，则会引发SIGABRT信号。
2. 在SIGABRT上调用Upstart崩溃处理程序。
3. 新贵的崩溃处理程序派生了一个子进程。
4. Upstart子进程重新发出该信号，导致该子异常退出。
5. 内核检测到子进程异常退出并调用apport，将核心文件传递给标准输入（由于/ proc / sys / kernel / core_pattern）。
6. apport将核心文件写入/ var / crash /中的磁盘。
7. PID 1等待其子项终止（仅在分配完成写入核心文件后才会发生）。
8. PID 1退出。
9. 内核恐慌。
10. 下次启动时，Whoopsie将检测到崩溃文件并进行处理。

后端

为了使延迟和对CPU / IO的影响尽可能小，/usr/share/apport/apport仅在崩溃的进程仍然存在时收集必须获取的数据：来自/proc/pid，核心转储，可执行路径和信号号的信息。该报告已写入/var/crash/executable_path.uid.crash。

前端调用

在Gnome中，update-notifier保持inotify监视/var/crash。每当有新内容时，它都会调用/ usr / share / apport / apport-checkreports。如果有新报告，它将调用/ usr / share / apport / apport-gtk，这是上面屏幕快照中显示的前端。

然后，前端收集其他信息，例如程序包版本，程序包文件校验和或操作系统版本，并调用所有匹配的程序包挂钩。要禁用此功能，您可以运行gsettings set com.ubuntu.update-notifier show-apport-crashes false（以您的普通桌面用户身份）。

基于启动板的自动回溯器

Canonical数据中心运行一项服务，该服务会自动评估带有错误的错误。通过根据启动板中的体系结构对错误进行标记，将完成回溯并删除标记。使用的标记是Need-i386-retrace或Need-amd64-retrace。请参阅公告。

每件包装的挂钩

包可以指定从系统收集并包含在错误报告中的信息。这些是通过包含在包中的apport挂钩完成的。有关一些有用的示例，请参见：

• source_xorg.py-将其他日志文件和硬件详细信息添加到错误报告
• usplash-忽略特定代码路径中的崩溃
• source_totem.py-向记者提问，并根据回复收集不同的信息

在/ usr / share / apport / package-hooks中。还提供了用于提供分配钩子的软件包列表。

如果崩溃或错误报告是通过apport提交的，则相关的挂钩将自动运行。如果您有一个已经报告的错误而没有进行批准就提交了，并且您对这些挂钩中的信息感兴趣，则可以要求错误报告者使用apport-collect错误号。

使用消息来源，卢克！

• 您可以从Launchpad项目页面下载上游tarball，也可以从Ubuntu存档下载Ubuntu源码tarball。
• apport是通过Launchpad上的集市RCS开发的。如果您想为它做贡献或开发基于它的自己的系统，则可以使用bzr获取您自己的分支，或者将trunk用作debcheckout -a分配给Ubuntu包装分支。

未来的计划

性能方面的各种改进，使用报表的更好工具以及更多语言（Mono / Python堆栈跟踪，断言消息等）的集成，请参见相关规范。

^{资料来源：Apport，如何分类和如何启用Apport}