Red Hat Bugzilla – Bug 1321675
CFME log_rotate_freespace_check.sh could awk on wrong field if filesystem name is long and wraps during df
Last modified: 2016-07-12 11:20:23 EDT
Description of problem: It was discovered that our postgresql.log file in our test environment contained data from the past year and was not being rotated. Was linked to BZ 1294991 as a possible cause of the problem. The proposed solution of updating logrotate_free_space_check.sh to change: logvol_free_space=`df -lk $file | awk '{ print $3 }' | tail -n 1` to awk on $4 instead of $3, is correct in gathering the correct field for free space. However, because of wrapping on a df output with a filesystem with a longer path, it can cause the wrapped output to awk on the wrong field. Version-Release number of selected component (if applicable): 5.3.4.2 How reproducible: Steps to Reproduce: 1. df -lk <file on filesystem with long name that forces a wrap> example: df -lk /opt/rh/postgresql92/root/var/lib/pgsql/data/pg_log/postgresql.log Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/vg_data-lv_pg 102176096 24228016 72758540 25% 2. df -lk <file on filesystem with long name that forces a wrap> | awk '{ print $4 }' 3. in this case, field 3 would be the correct free space. Actual results: Expected results: Additional info: My suggestion would be to use the "-P" flag with df to force the POSIX output format and output with no wrapping. example: 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 Suggested change: logvol_free_space=`df -Plk $file | awk '{ print $4 }' | tail -n 1`
This wrapping behavior no longer happens as of GNU coreutils version 8.10 (we run 8.22 in 5.6) so this is not an issue on current appliances. I am for reclassifying this as refactoring to clean up how that command is run to make what we are doing more explicit though. Maybe: df -lk --output=avail <filename> | tail -n 1 This way it is more explicit with df and can drop the awk because there will be no extraneous whitespace.
https://github.com/ManageIQ/manageiq-appliance/pull/69
This issue occurs in 5.5 as well. Can this BZ be cloned to 5.5? Also, https://bugzilla.redhat.com/show_bug.cgi?id=1294991 needs to be cloned to 5.5 as well.
New commit detected on ManageIQ/manageiq-appliance/master: https://github.com/ManageIQ/manageiq-appliance/commit/4eab5bc5e64d1bb24f6ee669dabef4795a4df398 commit 4eab5bc5e64d1bb24f6ee669dabef4795a4df398 Author: Nick Carboni <ncarboni@redhat.com> AuthorDate: Thu Apr 21 15:09:06 2016 -0400 Commit: Nick Carboni <ncarboni@redhat.com> CommitDate: Thu Apr 21 15:09:06 2016 -0400 Use reliable output formatting in df This avoids dealing with column counts and is more explicit about the value we are looking for. https://bugzilla.redhat.com/show_bug.cgi?id=1321675 logrotate_free_space_check.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
This should not be an issue in 5.5. The fix made here is strictly an enhancement to make the intention of the script more clear and less error prone in the future. As I said in comment 2 (https://bugzilla.redhat.com/show_bug.cgi?id=1321675#c2) this wrapping behavior is no longer seen in the version of coreutils shipped with RHEL 7, but would have been an issue in 5.3 (where this bug was reported). I'm not sure a clone is necessary for this issue, but it is no trouble if you really think we need it.
Nick, On one of me 5.5 appliances, evm.log failed to rotate and I was told that this bug and bug 1294991 would have to be backported to 5.5.z. If this issue doesn't impact coreutils shipped with RHEL 7 and hence CFME 5.5, cloning this bug to 5.5.z is not necessary.
Verified in 5.6.0.6
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. https://access.redhat.com/errata/RHBA-2016:1348