Question

我注意到我的系统一直在制作此崩溃报告。我不确定为什么，我对阿帕奇内心的了解有限。我不确定是什么导致了这一点，因为服务器上没有任何特别的变化。任何帮助表示赞赏。我应该寻找和检查什么？可能是什么原因？

Apport会：

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

_usr_sbin_apache2.0.crashProblemType： Crash report - To big for stackoverflow

感谢您的时间=）

Answer 1

x86 / ARM设备上的信号7与SIGBUS（请参阅：man 7 signal）相关，表示Bus error (bad memory access)。

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

请参阅：Debugging SIGBUS on x86 Linux

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

调试

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

要打开包装，运行：

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

请参阅：How can I read a crash file from /var/crash和Debugging Program 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进行更高级的调试，请参见：How to get current PHP function name in gdb?

与上面的示例类似，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。

Apache崩溃报告 - is_closing_session（）：环境中没有DBUS_SESSION_BUS_ADDRESS

1 个答案:

调试

PHP