Summary

This article describes how to help syslog-ng developers to diagnose and fix syslog-ng crash problems.

Compile with debug symbols

If you are compiling syslog-ng from source, include debug symbols using the '''--enable-debug''' configuration option or by passing the '''-g''' flag in the '''CFLAGS''' and '''LDFLAGS''' environment variables. This will produce a slightly larger syslog-ng binary which contains debug symbols. Dependencies should also be compiled with debug symbols. For most distributions debug information is contained in an additional package with a -dbg (Debian), -dbgsym (ubuntu) -debuginfo (Fedora/openSUSE) suffix.

Generating a core file

When syslog-ng crashes and the '''ulimit -c''' resource limit is set to ''unlimited'' or a large enough value, the operating system produces a core file upon crash. The location of the core file depends on how syslog-ng was started:

  • if started in the background, then the location of the PID file (usually /var/run/syslog-ng for OSE or /opt/syslog-ng/var for PE)
  • if started in the foreground, then the current directory

Make sure that the syslog-ng process has appropriate write permissions in this directory.

The name of the core file is somewhat OS dependent, it is usually simply named "core", but variations that include the pid number also exist.

Generating a backtrace

Once you have a binary that has debug symbols and a core file containing the memory map of the crash, you can generate a backtrace using '''gdb''' (the GNU Debugger) like this:

$ gdb /sbin/syslog-ng -c core (gdb) bt full ... ... backtrace output ...

Post the backtrace to the [https://lists.balabit.hu/mailman/listinfo/syslog-ng syslog-ng mailing list]. The developers of syslog-ng might request additional information; sometimes the complete core file is required to diagnose the problem.

Additional information

  • GDB documentation: http://sourceware.org/gdb/documentation/
  • Wikipedia page on core dumps: http://en.wikipedia.org/wiki/Core_dump