Hi, Hmm... the primary reason is that the state must be initialized in all cases and affile_sd_recover_state() either restores the old state or initializes a new one. In case the file doesn't exist when syslog-ng starts up, the state cannot be initialized. In these cases, LogReader will send an NC_FILE_MOVED notification once the file becomes available. In these cases the state is initialized by that affile_sd_recover_state() call. So, the problem with removing that may cause ill effects in the case the file becomes available while syslog-ng is already running. Why does it cause a spin in this usecase? On Wed, 2011-02-02 at 21:53 +0100, Gergely Nagy wrote:
On Wed, 2011-02-02 at 19:58 +0300, Mailing Lists wrote:
The patch did not solve the problem. Syslog-ng appears to loop over the empty source file.
The attached patch fixes the problem, but it may have unwanted side effects - although off the top of my head, I can't think of any, nor did my tests reveal anything.
Works For Me(tm) applies.
The proper solution will need a bit more thinking, unfortunately. I know why the problem appears, and I know why the attached fix works, but I do not understand the reason why the line I removed was there in a first place.
I suppose there was a reason behind it, but I've yet to figure that out.
In the meantime, the attached patch should help. I tried my best to find any ill side-effects, but so far, I couldn't. Therefore I think it's pretty safe, but no guarantees.
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.campin.net/syslog-ng/faq.html
-- Bazsi