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+