Bug 62787 - sshd Unmatched Entries run together in 2.6-1
Summary: sshd Unmatched Entries run together in 2.6-1
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: logwatch   
(Show other bugs)
Version: 7.2
Hardware: noarch Linux
Target Milestone: ---
Assignee: Elliot Lee
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2002-04-05 16:51 UTC by Chris Rode
Modified: 2008-05-01 15:38 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-15 17:42:28 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
proposed bug fix (819 bytes, patch)
2002-04-06 00:58 UTC, Michael Schwendt
no flags Details | Diff

Description Chris Rode 2002-04-05 16:51:56 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)

Description of problem:
In the 2.6-1 errata release, unmatched entries under sshd are running together, 
making it difficult to read.  Previously, each unmatched entry was on its own 
seperate line.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  Run logwatch
2.  See unmatched entries under sshd

Additional info:

Comment 1 Michael Schwendt 2002-04-06 00:58:05 UTC
Created attachment 52508 [details]
proposed bug fix

Comment 2 Paul Gear 2002-04-06 20:09:58 UTC
Please treat this with fairly high priority - it makes logwatch unusable and is
trivial to fix.

Comment 3 Andrew Bartlett 2002-04-07 04:06:03 UTC
Likewise it messes up sudo logs - where I would normally see a long string of
similar commands (becouse thats what I was doing) I get an unreadable single
line (wrapped by my MUA) unreadable log.

I agree, this needs a new errta, and soon!

Comment 4 Michael Schwendt 2002-04-07 12:09:47 UTC
It's a second bug in the handling of secure.log. My patch addresses both problems.

Comment 5 Bernd Bartmann 2002-04-10 08:17:54 UTC
Another thing I noticed after applying the logwatch update, is that all date 
and time informations are removed in the logwatch mails. Is this intended? I 
think I would be really much better to get the complete informations from the 
log files as it was before the update.

Comment 6 Paul Gear 2002-04-10 11:26:02 UTC
I'm not sure why it changed, but i find it much easier to read without the
times.  If you need exact times, you can always go to the logfile itself to get
them.  Perhaps an option to select the behaviour would be a good idea.

Comment 7 Michael Schwendt 2002-04-10 12:37:51 UTC
while (defined($ThisLine = <STDIN>)) {
   $ThisLine =~ s/^... .. ..:..:.. [^ ]+ //;

This is from /etc/log.d/scripts/services/secure, which handles /var/log/secure.
Here, newline, date, and PID are cut off when they match above format. It fails
to cut off entries like name[pid] or name(component)[pid], though.

The ChangeLog doesn't mention a clean-up job like this. But I would assume it
intends to increase readability. You want unusual information. Dates and PIDs
are not unusual. Hence they get dropped.

Comment 8 Elliot Lee 2002-04-15 18:13:21 UTC
Patch applied in 2.6-2

Comment 9 Paul Gear 2002-04-17 21:52:24 UTC
Where is the Rawhide version?  It's not at

Comment 10 Elliot Lee 2002-04-23 20:42:24 UTC
rawhide is not currently being pushed to the FTP site. No idea when it is coming
back. The package would be there though, honest. :)

Note You need to log in before you can comment on or make changes to this bug.