On 23/07/10 17:46, Sergey B Kirpichev wrote:
On Fri, Jul 23, 2010 at 4:31 PM, Ximin Luo<[email protected]> wrote:
Currently this package installs a cron job that runs every ten minutes. This
is a VERY bad idea:
- if logrotate(8) runs during those 10 minutes, some log entries will fail to
be accounted for by awstats
logrotate every 10 minutes - could be the source of trouble. Not awstats.
No, logrotate isn't running every 10 minutes. I think you misunderstood my
point. If logrotate runs between the 10-minute cron runs of awstats, it will
rotate the log entries since the last 10-minute run, so the next 10-minute run
won't be able to see it any more.
- it wastes resources parsing the same log files every 10 minutes, especially
if they get big
Do you mean, it parses _same_ log entires? No, awstats doesn't do
such a stupid things. Actually, it does lseek on file to the last
known entry and then begin parsing.
What if the file has been truncated or removed by logrotate?
- it makes logcheck(8) spam my inbox every hour due to the cron job failing
every 10 minutes
Why exactly it fails? Do you try first to comment out crontab entry
and fix the source of failure?
I guess because I haven't written a proper config file yet? Anyway, it's still
spamming my syslog *every 10 minutes*. This should at least be an option that's
off by default.
A better solution is to hook the update script onto the logrotate(8) entries
for any installed webservers (eg. /etc/logrotate.d/lighttpd,apache2). This
solves all of the 3 problems I just mentioned.
Package: awstats
Version: 6.9.5~dfsg-2
Severity: important
I'm disagree with severity. Looks like a very
site-specific/workload-specific issue. Your logrotate-based solution
could be suggested as an option in README.Debian for specific setups.
logrotate is part of the standard install for Debian webservers (at least
apache2 and lighttpd). this is not "site specific".
On Fri, Jul 23, 2010 at 5:31 PM, Jonas Smedegaard<[email protected]> wrote:
Frequent updates of logfiles have its use too, however. But not always -
and the backsides you raise here are valid.
True.
I suggest to a) split the current cron job into infrequent and frequent
jobs, b) make the frequent one optional (ideally through debconf), and c)
invoke the infrequent job also (or instead?) as a logrotate hook.
How to split a) or c)? It's easy only from the local admin side.
We can make cron job frequency to be debconfigured. Is it an option?
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
