Bug 172230 - logwatch breaks on a stricter sort
logwatch breaks on a stricter sort
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: logwatch (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ivana Varekova
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-01 14:16 EST by Michal Jaegermann
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-02 07:44:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2005-11-01 14:16:44 EST
Description of problem:

In /usr/share/logwatch/scripts/services/zz-disk_space on line 112 has an
obsolete "+4" option to sort and as result with sort from coreutils-5.92-1
it fails with "sort: open failed: +4: No such file or directory".

After replacing "+4" with "-k 5" logwatch starts work again.

AFAICS this is the only instance of using sort with "+<num>" option in all
logwatch scripts.

Version-Release number of selected component (if applicable):
logwatch-7.0-1
Comment 1 Michal Jaegermann 2005-11-01 14:52:11 EST
Come to think of it the line 112 of zz-disk_space is truly weird.
First it has grep feding awk instead of awk putting a regexp condition,
like '/^\//$awkprog', in front of $awkprog.  The second I do not understand
what an incriminated sort was supposed to achieve.  It sorts in
"64% %7 %87" order.  Was 'sort -b -n -k 5' really intended?  Or maybe even
'sort -b -r -n -k 5'?  This is not same thing as what is there now.
Comment 2 Ivana Varekova 2005-11-02 07:44:14 EST
Thank you for your bug report.
This problem is fixed in the last version (logwatch-7.0-2).

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