This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1294991 - CFME uses wrong value to determine volume freespace causing logrotate to fail
CFME uses wrong value to determine volume frees...
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance (Show other bugs)
x86_64 Linux
high Severity high
: GA
: 5.6.0
Assigned To: Nick Carboni
luke couzens
: ZStream
Depends On:
Blocks: 1321675 1334743
  Show dependency treegraph
Reported: 2015-12-31 09:06 EST by Thomas Hennessy
Modified: 2016-06-29 11:24 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1334743 (view as bug list)
Last Closed: 2016-06-29 11:24:39 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Thomas Hennessy 2015-12-31 09:06:51 EST
Description of problem: in a test environment with 1 1+GB production.log file logrotate fails due to a reported insufficient space condition.  a review of the script indicates that the script line 
logvol_free_space=`df -lk $file | awk '{ print $3 }' | tail -n 1` uses the$3 value from the returned command which is total uses space, not the $4 value which would show available space.

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

How reproducible:
review the appliance_console.log in the /var/www/miq/vmdb/log directory on any appliance active for > 24 hours.  Notice that the "available free space" value is approximately the size of the used space at the time the command is issued, not the larger value which on a new appliance should be close to 10GB ( or 10,000,000 1-k blocks)

Steps to Reproduce:

Actual results:

Expected results:

Additional info: changing the script line to reference $4 instead of $3 should correct the issue.
the shell script can be found in /opt/rh/cfme-appliance
Comment 3 CFME Bot 2016-01-08 12:06:25 EST
New commit detected on ManageIQ/manageiq-appliance/master:

commit 8b504cd4b3bd6e97fefd6e9c8b710e137eb051d0
Author:     Nick Carboni <>
AuthorDate: Fri Jan 8 11:10:33 2016 -0500
Commit:     Nick Carboni <>
CommitDate: Fri Jan 8 11:10:33 2016 -0500

    Change logrotate free space check script to read free space correctly
    Previously we were reading space used as free space. | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Comment 4 Douglas Jones 2016-03-28 13:10:30 EDT
While the old check of

  logvol_free_space=`df -lk $file | awk '{ print $3 }' | tail -n 1`

is incorrect in that it is pulling the wrong column. However: 

  logvol_free_space=`df -lk $file | awk '{ print $4 }' | tail -n 1` 

makes the assumption that the output is all on one line.  For filesystems that have longer names, it will wrap the output

                         98G   24G   70G  25% /opt/rh/postgresql92/root/var/lib/pgsql/data

so when $3 is awked, it has the potential to pull the "correct" field.  Which is probably why it was missed.

  df -lk /opt/rh/postgresql92/root/var/lib/pgsql/data/pg_log/postgresql.log 
  Filesystem           1K-blocks     Used Available Use% Mounted on
                       102176096 24228016  72758540  25% /opt/rh/postgresql92/root/var/lib/pgsql/data

My suggestion would be to use the "-P" flag with df to force the POSIX output format and output with no wrapping.

  df -Plk /opt/rh/postgresql92/root/var/lib/pgsql/data/pg_log/postgresql.log 
  Filesystem                1024-blocks     Used Available Capacity Mounted on
  /dev/mapper/vg_data-lv_pg   102176096 24228056  72758500      25% /opt/rh/postgresql92/root/var/lib/pgsql/data

So proposed change would be to change the function to:

  logvol_free_space=`df -Plk $file | awk '{ print $3 }' | tail -n 1`
Comment 5 Douglas Jones 2016-03-28 16:55:41 EDT
Created new BZ item 1321675 for proposed update.
Comment 7 Nick Carboni 2016-04-04 09:57:06 EDT
Felix, there will be no backport unless there is a cloned BZ with the cfme-5.5.z flag.
Comment 8 Nandini Chandra 2016-05-06 17:11:26 EDT
This issue is seen in 5.5 as well.Can this BZ be cloned to 5.5.z?
Comment 10 luke couzens 2016-05-13 11:41:47 EDT
Verified in
Comment 12 errata-xmlrpc 2016-06-29 11:24:39 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

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