[syslog-ng] Followed files that grow while syslog-ng is reloaded

[Evan Rempel]

The real world case for this is when the persistent file is of the wrong version, syslog-ng will
continue to run correctly, UNTIL such time as the persistent data is needed, it won't be available.

syslog-ng should remove the persistent file (or rename it) and make a new one if it is out of date,
or invalid for any reason.

So upgrading from 2.x to 3.x (there may be other cases) and not removing that file will yield the
result you are seeing.

Evan.
________________________________________
From: syslog-ng-bounces at lists.balabit.hu [syslog-ng-bounces at lists.balabit.hu] On Behalf Of Francois Durand [fdur559 at gmail.com]
Sent: Wednesday, July 04, 2012 8:31 AM
To: Syslog-ng users' and developers' mailing list
Subject: Re: [syslog-ng] Followed files that grow while syslog-ng is reloaded

On Wed, Jul 4, 2012 at 10:54 AM, Gergely Nagy <algernon at balabit.hu<mailto:algernon at balabit.hu>> wrote:
Francois Durand <fdur559 at gmail.com<mailto:fdur559 at gmail.com>> writes:

> Then I guess I'll have to try 3.4.

I would suggest 3.3 instead (particularly, git head of it, or 3.3.6
which should be out in a week), 3.4 is at the moment, a development
tree, while the 3.3 branch is stable, and aimed at production use.

ok, thanks for the hint!

> That may solve another issue I have, that may be related. I have several
> webservers whose logs are transfered and aggregated on one central box in
> the same file. I did not investigate enough to make a full report, but the
> central log file is corrupted (different lines seem to mix!) and it seems
> to me that's related to the previous fact since it seems to happen only to
> files that are reread from the start.

Do you have a single file destination, to which these logs are routed to
on the central server, or different destinations with the same file set?

Each webserver serves many virtual hosts. Each virtual host has one access.log. So for instance, on server 1, we have s1v1.log for vhost 1 and s1v2.log for vhost 2. On server 2, we have s2v1.log and s2v2.log. Then s1v1.log and s2v1.log are aggregated on the central log box into v1.log, and s1v2.log and s2v2.log into v2.log.