Re: logcheck gaps in time
On Tue, Jun 05, 2001 at 07:58:50AM -0500, hanasaki wrote:
> I have added the following else statement to the script
> so there is always a report. I would appreciate it if the utility's owner would
> consider adding this to his/her next revision and giving a small credit if they do.
I would not appreciate it. I suppose adding an option (so long as
the current behaviour remains the default) would be OK, but I'm of the
opinion that, if there's nothing to report, I don't want to be bothered
with null mail. The absence of a problem report is itself confirmation
that there is no problem. (Same principle: Create an empty directory,
cd into it, and do an `ls`. Does ls say "There are no files to display"?
No. It just displays the names of the files, which happens to be
an empty list.)
Anyhow, what you report is, as I indicated above, normal behaviour. I've
been running logcheck for quite a while and I've never gotten mail from it
unless it had some perceived anomaly to report. If you still have copies of
any of your old "Nothing is wrong" notifications, I would like to see one.
There's probably something in them that you consider so normal that it must
have been ignored, but it actually triggered logcheck.
As for verifying that everything really is OK, the first thing to do is...
Look at your logs manually. Assuming you're running syslogd with the default
settings, you should see entries saying "-- MARK --" every 20 minutes of
inactivity. If there are any gaps larger than 20 minutes, then either
syslogd has had its timestamp interval changed or a chunk of the file is
missing.
The other thing to watch for is that logtail (called by logcheck to get only
the new portion of the log file) will issue a warning if a log file shrinks,
and logcheck will mail this warning like any other problem.
logcheck not sending you anything does not indicate any sort of problem. (I
would actually like to be able to make it more selective about what it sends.
Say, for instance, to ignore one failed login attempt by a user (he probably
just mistyped his password), but report 4 or more failed logins, whether by
the same user or each by a different user (that could be someone trying to
brute-force the machine). This would require a bit of extra complexity,
though, as the current purely-grep-based approach doesn't lend itself to that
sort of state maintenance.)
--
That's not gibberish... It's Linux. - Byers, The Lone Gunmen
Geek Code 3.12: GCS d? s+: a C++ UL++++$ P++>+++ L+++>++++ E- W--(++) N+
o+ !K w--- O M- V? PS+ PE Y+ PGP t 5++ X+ R++ tv+ b+ DI++++ D G e* h r y+
Reply to: