Yes. Use a source line like this in your conf file to read kernel messages, too.

source src { file("/proc/kmsg"); unix-stream("/dev/log"); internal(); };


There is problem caused by the ''/proc/kmsg'' implementation of the kernel, namely, when two parallel processes open and try to read from the ''/proc/kmsg'' file.

This special file is the userspace interface for collecting kernel log messages. If there are multiple processes reading ''/proc/kmsg'', a race condition occurs and the process which loses the race essentially deadlocks until the next kernel message is generated, when a new race condition occurs.

If the system logger is blocked and is not processing userspace messages, slowly all system daemons stall while waiting for the system logger to become available again. This includes crucial system components like '''sshd''' or the application handling system logins.

There are two alternative solutions for processing kernel messages on Linux systems:

  • using '''klogd''' from the sysklogd package
  • reading ''/proc/kmsg'' from syslog-ng natively, without using the '''klogd''' daemon

The second method is recommended.

The solution to this problem is to avoid running multiple userspace components that touch ''/proc/kmsg''. If you configure syslog-ng to read kernel messages, ensure that '''klogd''' is not running. If you want to run '''klogd''', ensure that '''syslog-ng''' does not read ''/proc/kmsg''.


syslog-ng OSE 2.0.7 & syslog-ng PE 2.1.9 includes a workaround for this problem, which wakes up syslog-ng after 10 seconds of blockage. This still means that the system is essentially stalled for 10 seconds every time syslog-ng loses this race, however, the system does not need to be power-cycled to resolve the situation.