Bug 62787 - sshd Unmatched Entries run together in 2.6-1
sshd Unmatched Entries run together in 2.6-1
Product: Red Hat Linux
Classification: Retired
Component: logwatch (Show other bugs)
noarch Linux
medium Severity medium
: ---
: ---
Assigned To: Elliot Lee
Depends On:
  Show dependency treegraph
Reported: 2002-04-05 11:51 EST by Chris Rode
Modified: 2008-05-01 11:38 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-15 13:42:28 EDT
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-05 19:58 EST, Michael Schwendt
no flags Details | Diff

  None (edit)
Description Chris Rode 2002-04-05 11:51:56 EST
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-05 19:58:05 EST
Created attachment 52508 [details]
proposed bug fix
Comment 2 Paul Gear 2002-04-06 15:09:58 EST
Please treat this with fairly high priority - it makes logwatch unusable and is
trivial to fix.
Comment 3 Andrew Bartlett 2002-04-06 23:06:03 EST
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 08:09:47 EDT
It's a second bug in the handling of secure.log. My patch addresses both problems.
Comment 5 Bernd Bartmann 2002-04-10 04:17:54 EDT
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 07:26:02 EDT
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 08:37:51 EDT
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 14:13:21 EDT
Patch applied in 2.6-2
Comment 9 Paul Gear 2002-04-17 17:52:24 EDT
Where is the Rawhide version?  It's not at
Comment 10 Elliot Lee 2002-04-23 16:42:24 EDT
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.