Apache crash report - is_closing_session (): no DBUS_SESSION_BUS_ADDRESS in the environment

Question

I noticed that my system produces this crash report. I'm not sure why, and my knowledge of Apache's internal behavior is limited. I'm not quite sure what is causing this, since nothing has changed much on the server. Any help is appreciated. What should I search and research? What could be the reason for this?

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 

Answer 1

Signal 7 on x86 / ARM devices belongs to SIGBUS (see: man 7 signal ), it means a bus error (poor memory access) .

A bus error is a hardware error that notifies the operating system (OS) that a process is trying to access memory that the CPU cannot physically address: an invalid address for the address bus, hence the name. In modern use on most architectures, this is much less common than segmentation errors, which occur mainly due to memory access violations: problems with the logical address or access rights.

See: Debugging SIGBUS on x86 Linux

This could be a bug, a faulty Apache module, or a hardware problem.

debugging

Since Apport generates a crash in /var/crash/ , you can check the crash file for more details. You can open it in a text editor, however the core dump file is packaged in base64 format.

To unzip it, run:

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

See: How can I read the crash file from / var / crash & Debug Crash .

Then run gdb to analyze the failure file:

 gdb $(cat _unpacked/ExecutablePath) _unpacked/CoreDump 

then type: bt or bt full to check the stack trace.

Assuming your Apache binary was not compiled with debugging symbols, this will not help much. However, you can determine where the failure occurred, such as, for example, a specific Apache / PHP module:

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

Also check how many frames you have by scrolling through the list with the bt command, and if there are too many, for example, more than 1000, the potential problem is with an infinite loop somewhere in your code application.

Php

If your application runs under PHP, for more complex debugging using gdb see: How to get the name of the current PHP function in gdb?

As in the above example, the libphp5.so module is the main one that works with PHP.

To find out which package it belongs to, run:

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

Then consider updating the failed library / module.

If a third-party module php5dismod , consider disabling it with php5dismod , for example

 $ 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 

Then, if the problem still exists, try reproducing it from the command line using php . If you can, debug it with strace , for example

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

Then check the last steps that the PHP process performed before the crash. To increase the size of messages, use -s 1500 , to save to a log file, use -o file.log .