[syslog-ng] Behavior when followed files are renamed

[Joe Shaw]

Hi,

On Thu, Dec 11, 2008 at 5:37 PM, Balazs Scheidler <bazsi at balabit.hu> wrote:
> On Thu, 2008-12-11 at 15:23 -0500, Joe Shaw wrote:
>> I couldn't find this anywhere in the online docs.  What's the behavior
>> of syslog-ng OSE when a file which is being followed with
>> follow_freq() is renamed?
>
> It will be read until EOF, and then if a new file happens to be there at
> the same location, syslog-ng starts reading the new file. e.g. it
> handles rotated logfiles just fine. Although I don't know if this is
> your intention or not.

Ah, ok, thanks for the info!  I think this is probably what I want,
but I am worried about a race condition.  Consider the following
scenario:

1. Some app is writing to a log file, and another program is
monitoring when the logs should be rolled.

2. The log rolling program renames the file on disk, and the app
continues to write to the renamed file because it still has a file
descriptor open to it.

3. The log rolling program signals to the app to close and reopen its
log file; the app is writing out to its fixed log file location again.

Assuming that syslog-ng is monitoring the file, is there a possibility that:

1. The file is renamed
2. syslog-ng is fully caught up and hits the EOF
3. The new file isn't created yet, but syslog-ng is waiting for it to be created
4. The app continues to write some data out to the old, renamed file
5. The app is signaled and reopens the file; syslog-ng starts monitoring it

I am making an assumption in #3 which might not be true -- that
syslog-ng when it encounters EOF but the file isn't recreated that
it'll abandon the renamed file.  If that's not true, then there's no
race and I'm happy. :)

> As far as I know the tarball does not contain the documentation either. It
> is currently maintained completely separately from syslog-ng, but
> the documentation team, thus the authentic source for syslog-ng documentation
> is at http://www.balabit.com/support/documentation/. It is available in
> both HTML and PDF format under Creative Commons. Also, I can create a
> public git repository of the documentation if someone is willing to
> contribute patches :)

Ah, ok, that's what I've been using as a reference to-date.

Thanks,
Joe