7.2. abrt, libreport and btparser

Bug Fixes

BZ#799909

When the user attempted to remove a non-existing problem directory using the abrt-cli utility, abrt-cli emitted a confusing error message, such as in the following example:

# abrt-cli rm sdfsdf
'sdfsdf' does not exist
Can't connect to '/var/run/abrt/abrt.socket': Connection refused

With this update, abrt-cli has been modified to display only a message informing that such a problem directory does not exist.

BZ#808721, BZ#814594

When multiple kernel oopses occur in a short period of time, ABRT saves only the first oops because the later oopses are mostly only consequences of the first problem. However, ABRT sorted the processed oopses incorrectly so that the last oops that occurred was saved instead of the first oops. With this update, ABRT has been modified to process multiple kernel oopses in the correct order so that ABRT now saves the first oops as expected.

BZ#810309

Due to incorrect configuration, ABRT attempted to use the abrt-bodhi command, which is not available in Red Hat Enterprise Linux, while analyzing a backtrace. As a consequence, the user could see the following error message in the problem backtrace:

/bin/sh: line 6: abrt-bodhi: command not found

However, the error message had no influence on the problem reporting process. This update corrects the ABRT configuration so that the abrt-bodhi command is removed from the analyzer events and the error message no longer occurs.

BZ#811901

Previously, ABRT expected the dbus-send command to be always present on a system. However, ABRT does not depend on the related dbus package so there is no guarantee that the command is installed on the system. Therefore, when processing events that use the dbus-send command and the dbus package was not installed, ABRT emitted the following error message to the system log:

abrtd: /bin/sh: dbus-send: command not found

With this update, ABRT has been modified to verify the existence of dbus-send before attempting to call this command. The aforementioned error messages no longer occur in the system log.

BZ#813283

Previously, when running the report-gtk command with a non-existing problem directory, ABRT GUI attempted to process the problem directory. As a consequence, the terminal was flooded with GTK error messages. With this update, the ABRT GUI has been modified to no longer process non-existing problem directories. GUI now only prints a message informing that the processed directory does not exist and exits gracefully.

BZ#817051

The report tool always had to be executed from a problem directory even to perform actions which do not require the problem directory, such as adding an attachment to the existing bug report. When running from a directory that was not a problem directory, the report tool failed with the following error message:

'.' is not a problem directory

With this update, the report tool has been modified to not require a problem directory if the "-t" option is specified. The report tool can now be used to update existing bug reports without a need to run inside a problem directory.

BZ#815339, BZ#828673

Due to an error in the default libreport configuration, ABRT attempted to run the reporter-bugzilla command, which is not installed by default. This caused the following warning message to appear during problem reporting:

/bin/sh: line 4: reporter-bugzilla: command not found

However, the reporting process was not affected by this warning message. With this update, the default configuration of libreport has been corrected and reporter-bugzilla is no longer called by ABRT in the default configuration. The aforementioned warning message is no longer displayed during the reporting process.

BZ#820475

Previously, the abrt-ccpp init script did not emit any status message so that the service abrt-ccpp status command did not display any output. This update corrects the abrt-ccpp init script so that if the abrt-ccpp service is running the "abrt-ccpp hook is installed" message is displayed. If abrt-ccpp is stopped, the "abrt-ccpp hook is not installed" message appears.

BZ#826745

Certain ABRT libraries were previously built with wrong linker parameters and when running prelink on these libraries, the process returned error messages that the library contains "undefined non-weak symbols". With this update, the related makefiles have been corrected and the aforementioned errors no longer occur during prelink phase.

BZ#826924

ABRT ran the sosreport utility whenever a problem was detected. However, if the detected problem was caused by sosreport, ABRT could run sosreport in an infinite loop. Consequently, abrtd became unresponsive with extensive consumption of system resources. This update modifies ABRT to ignore consequent crashes in the same component that occur within a 20-second time period. The abrtd daemon no longer hangs if sosreport crashes.

BZ#847227

ABRT previously moved captured vmcore files from the default location in the /var/crash/ directory to the /var/spool/abrt/ directory. This affected the functioning of various tools that expected a vmcore file to be present in the /var/crash/ directory. This update modifies ABRT to use the CopyVMcore configuration option to specify whether to copy or move the core file. By default, ABRT no longer moves vmcore from the /var/crash/ directory but copies it.

BZ#847291

When disk space usage of the /var/spool/abrt/ directory reaches the specified disk space quota, ABRT finds and removes the largest problem directory. However, ABRT was previously unable to handle situations when the largest directory in /var/spool/abrt/ was not a problem directory. ABRT could not remove this directory and entered an infinite loop while searching for the largest directory to be removed. This update modifies ABRT to exclude unknown directories when determining which problem directory needs to be removed. The abrtd daemon no longer hangs in this scenario.

BZ#856960

When configured for centralized crash collection, ABRT previously printed logging credentials in plain text into the /var/log/messages log file on a dedicated system while uploading a crash report. This was a security risk, and so ABRT has been modified to no longer print the libreport-plugin-reportuploader plug-in credentials in log messages.

BZ#873815

When processing a large amount of problems, the inotify handling code could become out of sync, causing abrtd to be unable to read inotify events. Eventually, abrtd became unresponsive while trying to read an inotify event. If this happened and a Python application attempted to communicate with ABRT, abrtd and the Python application entered a deadlock situation. The daemon was busy trying to read an incoming inotify event and the Python script was waiting for a response from abrtd, which caused the application to become unresponsive as well. With this update, the ABRT exception handler sets timeout on a socket used for communication between abrtd and Python scripts, and also the inotify handling code has been modified. The abrtd daemon and Python applications no longer hang, however under heavy load, the inotify handling code can still become out of sync, which would cause abrtd to stop accepting new problems. If abrtd stops accepting new problems, it has to be restarted to work correctly again.