On Sun, 2011-02-06 at 11:24 +0100, Gergely Nagy wrote:
Why does it cause a spin in this usecase?
It goes into a spin, because even if the file was reopened, _recover_state() will end up calling log_proto_buffered_server_apply_state() which will lseek to an offset past EOF.
I'm not entirely sure why it will do that, however - there's two scenarios that can happen, and I'm not sure which one we end up in. I'll test it as soon as possible.
Anyway, being past EOF will trigger NC_FILE_MOVED again, and we start the whole process again, and again, and again.
Come to think of it, the problem is probably an inconsistency in state, but that's just my gut feeling at the moment.
I'll have a closer look at this later today.
hmm.. I remember fixing something like this. Here it is: Author: Balazs Scheidler <bazsi@balabit.hu> 2010-11-07 15:03:27 Committer: Balazs Scheidler <bazsi@balabit.hu> 2010-12-10 16:14:09 Parent: ee1d0d7f0720c3ded0d2bfaf22ca6e42d669b7a6 (separate directory hierarchy into lib/, modules/ and syslog-ng/) Child: 26b70812cae04179c939dc8b1f323a24692a30f5 (Performance improvement: file write uses writev instead of per-message write() to write larger chunks) Branches: many (24) Follows: v3.2.1 Precedes: LogProto: apply_state shouldn't allow file offsets over the end-of-file Assume that the file was truncated in this case. It is probably present in 3.3 only. Can you check if backporting that patch fixes the spinning too? -- Bazsi