Apache 崩溃报告 - is_closing_session():环境中没有DBUS_SESSION_BUS_ADD

Question

我注意到我的系统一直在生成此崩溃报告。我不确定为什么，我对apache内部的了解是有限的。我不太确定是什么原因造成的，因为服务器上没有任何特别的变化。任何帮助，不胜感激。我应该寻找和检查什么？可能是什么原因？

适用时间：

ERROR: apport (pid 8618) Mon Jan 25 14:35:24 2016: called for pid 8384, signal 7, core limit 0
ERROR: apport (pid 8618) Mon Jan 25 14:35:24 2016: executable: /usr/sbin/apache2 (command line "/usr/sbin/apache2 -k start")
ERROR: apport (pid 8618) Mon Jan 25 14:35:24 2016: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment
ERROR: apport (pid 8618) Mon Jan 25 14:35:52 2016: wrote report /var/crash/_usr_sbin_apache2.0.crash

Answer 1

x86/ARM 设备上的信号 7 与SIGBUS有关（请参阅：man 7 signal ），表示总线错误（内存访问错误）。

总线错误是由硬件引发的故障，通知操作系统 （OS） 进程正在尝试访问 CPU 无法物理寻址的内存：地址总线的地址无效，因此得名。在大多数体系结构的现代使用中，这些错误比分段错误要少得多，后者主要是由于内存访问冲突而发生的：逻辑地址或权限中的问题。

请参阅： 在 x86 Linux 上调试 SIGBUS

可能是错误，错误的Apache模块或硬件问题。

调试

由于 Apport 在 /var/crash/ 中生成了崩溃，因此您可以查看崩溃文件以获取更多详细信息。您可以在文本编辑器中打开它，但核心转储文件以 base64 格式打包。

要解压缩它，请运行：

cd /var/crash
sudo apport-unpack /var/crash/_usr_sbin_apache2.0.crash _unpacked

请参阅：如何从/var/crash 和调试程序崩溃中读取崩溃文件。

然后运行gdb来分析崩溃文件：

gdb $(cat _unpacked/ExecutablePath) _unpacked/CoreDump

然后键入：bt 或 bt full 以检查堆栈跟踪。

假设您的 Apache 二进制文件不是使用调试符号编译的，它不会有太大帮助。但是，您可以确定崩溃发生的位置，例如某些 Apache/PHP 模块，例如：

Program terminated with signal X, ...
#0  0x00007f39a616e09a in ?? () from /usr/lib/apache2/modules/libphp5.so

还可以通过从命令中滚动列表来检查您有多少帧bt如果帧太多，例如超过 1000 帧，则潜在问题在于代码应用程序中某处的无限循环。

.PHP

如果您的应用程序在 PHP 下运行，有关使用 gdb 进行更高级的调试，请参阅： 如何在 gdb 中获取当前的 PHP 函数名称？

就像上面的例子一样，libphp5.so模块是处理PHP的主要模块。

要找出它属于哪个包，请运行：

$ dpkg -S /usr/lib/apache2/modules/libphp5.so
libapache2-mod-php5: /usr/lib/apache2/modules/libphp5.so

然后考虑升级有故障的库/模块。

如果某些第三方模块崩溃，请考虑通过php5dismod禁用它，例如

$ sudo apachectl -M
Loaded Modules:
...
$ sudo a2dismod somemodule
$ php -m
$ sudo php5dismod somemodule # Optionally.
$ sudo apachectl configtest
Syntax OK
$ sudo service apache2 reload
 * Reloading web server config apache2

然后，如果问题仍然存在，请尝试使用 php 从命令行重现它。如果可以，请使用strace进行调试，例如

$ strace -f php myscript.php
...
gettimeofday({1560725354, 768601}, NULL) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)

然后检查 PHP 进程在崩溃之前正在执行的最新操作。要增加消息的大小，请使用 -s 1500 ，要保存到日志文件中，请使用 -o file.log 。