Hi, On Sat, Feb 26, 2011 at 9:09 PM, Aleksei Plotnikov <quadrun@hot.ee> wrote:

Hello,

In "syslog-ng 3.0 Administrator Guide" one of options for unix-stream and unix-datagram sources is "follow_freq", which is default 1 according to manual. But when I explicitly set it in source config to "unix-stream("/dev/log" follow_freq(1))" or any other positive value, syslog-ng start to consume all memory and than crashes after some time. Also log is full of such messages:

 "syslog-ng[11189]: Error invoking seek on followed file; error='Illegal seek (29)'"

follow_freq meant to be available for regular files only so it's definitely a bug that it's settable for non-file sources.

and when I do strace on syslog-ng process, it shows:

 lseek(12, 0, SEEK_CUR)                  = -1 ESPIPE (Illegal seek)  lseek(13, 0, SEEK_CUR)                  = -1 ESPIPE (Illegal seek)  lseek(14, 0, SEEK_CUR)                  = -1 ESPIPE (Illegal seek)

and 12,13,14 is file descriptors for /dev/log. Looks like syslog-ng is trying to lseek on socket, what is not possible. It happened when I tried different syslog-ng versions 3.0.5 and 3.1.2 on debian lenny 5.0.6 and ubuntu 10.10. So, is follow_freq applicable in such case and maybe it should be noted in manual?

no, it shouldn't be there at all

Also is it possible to make /dev/log not-blocking to sender, when syslog-ng cannot process messages from it. In our case, when follow_freq was set to 1, syslog-ng was not able to read from /dev/log/ - other processes which were sending logs to /dev/log are stucked too. It happens with both unix-stream and unix-dgram sockets. Or is there any good way to avoid such behaviour?

The blocking happens only when there is a reader of /dev/log and it doesn't work so the obvious fix is to have a working syslog daemon running... Regards, Sandor