From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1 Description of problem: When logwatch searches logs for the cron service, it does not properly check for a '-' (dash) in the hostname and therefore fails. It only searches for regex \w which does not include the dash character. I will send a "diff -l" to show the fix. Version-Release number of selected component (if applicable): logwatch-4.3.1-2 How reproducible: Always Steps to Reproduce: 1.change hostname to have a dash example: d123-123-123-123.bchsia.telus.net 2.run "logwatch --service cron --print" 3. Actual Results: this will produce output similar to: "**Unmatched Entries** Nov 2 04:20:00 d123-123-123-123 CROND[2115]: (root) CMD (/usr/local/scripts/check_ip/check_ip.sh) Expected Results: should have returned nothing. Additional info:
Created attachment 95830 [details] diff of original /etc/log.d/scripts/services/cron and patched copy I am not too familair with the process as it is my first submission. I have attached a "diff -l" and called it a patch, I hope that is the correct process/terminalogy.
Just changed the string a bit more as it was allowing a hostname consisting of only (one or more) dashes. Change string: Original s/^... .. ..:..:.. \w+ \w+\[\d+\]: \((\S+)\)\s+// 1st fix: s/^... .. ..:..:.. [-\w]+ \w+\[\d+\]: \((\S+)\)\s+// 2nd fix: s/^... .. ..:..:.. [-*\w+]+ \w+\[\d+\]: \((\S+)\)\s+// actual change between 1st fix & 2nd is: [-\w]+ became [-*\w+]+ (new diff attached)
Created attachment 95832 [details] output of 'diff -l' on the original cron file and the 2nd fix. corrects first fix that allowed hostname of all dashes.
Created attachment 95865 [details] just cleaned old commented lines from new file. (cleaner diff)
Thanks Pete - that is exactly what I've been seeing, and I've finally got round to looking at it. It is probably worthwhile bearing in mind that many places (ISPs especially) use naming standards, and use a "-" as a separator (eg web-1, etc). This is why we hit it.
*** Bug 110291 has been marked as a duplicate of this bug. ***
Looks like the latest logwatch has a fix for this issue.