[syslog-ng] [Bug 84] Program destination blocks if program stops reading input

[bugzilla at bugzilla.balabit.com]

https://bugzilla.balabit.com/show_bug.cgi?id=84


Balazs Scheidler <bazsi at balabit.hu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|                            |FIXED
             Status|NEW                         |RESOLVED




--- Comment #5 from Balazs Scheidler <bazsi at balabit.hu>  2010-06-06 13:47:49 ---

I could successfully fix this issue. As I wrote in the previous comment, this has nothing to do with flow-control. Rather it was a flush-timeout() handling
issue,
it didn't poll the destination, but rather assumed that it became writable after flush_timeout elapsed.

Others probably didn't notice this problem, because the problem "fixes" itself after the destination became writable. However in this time periods (between
flush_timeout and the time the destination became writable) syslog-ng was spinning the CPU.

So this problem definitely should account for some CPU usage, even in environments where it didn't cause critical problems.

Again, thanks for noticing and taking the time to track it down.

This patch seems to fix the issue for me:

Author: Balazs Scheidler <bazsi at balabit.hu>  2010-06-06 13:24:48
Committer: Balazs Scheidler <bazsi at balabit.hu>  2010-06-06 13:24:48
Parent: 5f82516db500209df040215c39da1b5adfc4d143 (main: stay in foreground if syntax-check or debug is requested)
Branches: master, remotes/balabit/master, remotes/origin/master
Follows: v3.0.6
Precedes: 

    logwriter: fixed flush_timeout handling on non-file destinations

    Non-file destinations may not always be willing to accept messages, which
    means that even if the flush_timeout elapsed, the destination may not be
    ready to accept messages.

    However log_writer_fd_prepare() basically assumed that once the timeout
    elapses we can immediately start writing messages (which is true for
    file destinations but false for others).

    This patch fixes this case.

    Kudos to Evan who helped me to track down this issue.

    Reported-By: Evan Rempel


-- 
Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.