Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Fixes in *free* output
With the introduction of the human readable ("-h") switch in the *free* tool, the layout generator had to be modified to support the new feature. This, however, affected printing of values longer than the column width. The values were truncated to prevent the layout from breaking when the values became longer than the reserved space in the columns. At the same time, the change caused *free* to insert an unwanted space character at the end of each line. Due to these two changes, the output could not be used in custom scripts. With this update, values longer than the column width are no longer truncated, no extra spaces are inserted at line ends, and the output of the *free* tool can now be processed without problems.
Description of problem:
/usr/bin/free shows wrong byte count (mega- and kilobytes are correct)
Version-Release number of selected component (if applicable):
procps-3.2.8-33.el6.x86_64
How reproducible:
free -b (bytes) shows more used memory than the total
$ /usr/bin/free -b
total used free shared buffers cached
Mem: 1672607334 3589210112 1313686323 707506176 118784000 1448566784
-/+ buffers/cache: 2021859328 1470421401
Swap: 4227854336 0 4227854336
3'589'210'112 is bigger than 1'672'607'334 (the total is wrong: the machine has 16GB of RAM and not less than 2)
Using -m (megabytes), -k (kilobytes) or -g (gigabytes) produces the expected result
$ /usr/bin/free -k
total used free shared buffers cached
Mem: 16334056 3507132 12826924 690924 116168 1414664
-/+ buffers/cache: 1976300 14357756
Swap: 4128764 0 4128764
or
$ /usr/bin/free -m
total used free shared buffers cached
Mem: 15951 3424 12526 674 113 1381
-/+ buffers/cache: 1929 14021
Swap: 4031 0 4031
or
$ /usr/bin/free -g
total used free shared buffers cached
Mem: 15 3 12 0 0 1
-/+ buffers/cache: 1 13
Swap: 3 0 3
Steps to Reproduce:
1. execute /usr/bin/free -b
Actual results:
Wrong total count (1'672'607'334)
Expected results:
Exact total count
Additional info:
Comment 2Evgheni Dereveanchin
2015-08-02 13:15:19 UTC
It's not that one value is higher than the other - in fact values in bytes are just truncated to the first 10 digits! This is a regression causing incorrect data to be displayed.
Here's my box with 20 GB of SWAP:
procps-3.2.8-30.el6:
# free -m
total used free shared buffers cached
Mem: 7852 2311 5541 8 144 938
-/+ buffers/cache: 1228 6623
Swap: 19999 0 19999
# free -b
total used free shared buffers cached
Mem: 8234053632 2448404480 5785649152 8908800 151695360 983752704
-/+ buffers/cache: 1312956416 6921097216
Swap: 20971515904 0 20971515904
procps-3.2.8-33.el6:
# free -m
total used free shared buffers cached
Mem: 7852 2347 5505 8 144 935
-/+ buffers/cache: 1268 6584
Swap: 19999 0 19999
# free -b
total used free shared buffers cached
Mem: 8234053632 2460778496 5773275136 8908800 151068672 980430848
-/+ buffers/cache: 1329278976 6904774656
Swap: 2097151590 0 2097151590
Compare the numbers of total SWAP - hopefully the issue is obvious to spot.
In fact all values are truncated to the first 10 digits, doesn't matter what unit is chosen. I tried that with very high values and even values in kilobytes were truncated.
The thing is that values longer than 10 digits break the layout and there's no easy way out of this. The unit conversion function that was introduced with the human readable switch truncates the value to 10 characters in order to preserve the layout.
Two possible options how to resolve this issue exist. We could add the '+' sign as the last character in order to tell the user, that the value is longer than the column width. Another option would be to break the layout (like it was in the past) and make the output not very well readable.
I would break the layout but this is just my opinion.
In any case we could also drop the -b option (since the original values are read from /proc/meminfo in KB)
(In reply to Matteo Corti from comment #6)
> I would break the layout but this is just my opinion.
Well. Even when it looks ugly, I admit it's probably a better solution, since some users might use the output of 'free' for scripting. With the added '+' sign they would end up with incorrect information and that would be a regression as well.
Moreover, the second option is an easyfix/oneliner...
---------------------
diff --git a/procps-3.2.8-free-human-readable.patch b/procps-3.2.8-free-human-readable.patch
index 1b3cd40..bfd5d63 100644
--- a/procps-3.2.8-free-human-readable.patch
+++ b/procps-3.2.8-free-human-readable.patch
@@ -21,7 +21,7 @@ diff -Naur procps-3.2.8.orig/free.c procps-3.2.8/free.c
+char *S(unsigned long long X)
+{
+ const char *unit = "BKMGT";
-+ static char buf[11], buf2[11];
++ static char buf[41], buf2[11];
+ int i;
+
+ if (human_readable) {
---------------------
The output buffer just needs to be increased in size. I hope 40 characters is sufficient.
> In any case we could also drop the -b option (since the original values are
> read from /proc/meminfo in KB)
That would be a regression as well. We need to keep all features intact.
I agree, removing the -b option would not be the best option (but we could mention in the man page that the base value is in KB, and that -b will not be preciser).
An I also agree on the breaking the formatting, otherwise it will break scripts.
Comment 10Evgheni Dereveanchin
2015-08-04 07:05:48 UTC
"free" output is actively used for processing with scripts so correctness of data must take precedence over prettyness in my opinion. Removing the -b option will also break existing scripts people might have on their RHEL deployments so it should be retained.
Hi,
we were hit by that issue as our backup software we use (Arkeia) currently uses the -b option for some calculations. Removing or changing this option would break this.
So pleas fix it and don't drop it!
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://rhn.redhat.com/errata/RHBA-2016-0904.html
Description of problem: /usr/bin/free shows wrong byte count (mega- and kilobytes are correct) Version-Release number of selected component (if applicable): procps-3.2.8-33.el6.x86_64 How reproducible: free -b (bytes) shows more used memory than the total $ /usr/bin/free -b total used free shared buffers cached Mem: 1672607334 3589210112 1313686323 707506176 118784000 1448566784 -/+ buffers/cache: 2021859328 1470421401 Swap: 4227854336 0 4227854336 3'589'210'112 is bigger than 1'672'607'334 (the total is wrong: the machine has 16GB of RAM and not less than 2) Using -m (megabytes), -k (kilobytes) or -g (gigabytes) produces the expected result $ /usr/bin/free -k total used free shared buffers cached Mem: 16334056 3507132 12826924 690924 116168 1414664 -/+ buffers/cache: 1976300 14357756 Swap: 4128764 0 4128764 or $ /usr/bin/free -m total used free shared buffers cached Mem: 15951 3424 12526 674 113 1381 -/+ buffers/cache: 1929 14021 Swap: 4031 0 4031 or $ /usr/bin/free -g total used free shared buffers cached Mem: 15 3 12 0 0 1 -/+ buffers/cache: 1 13 Swap: 3 0 3 Steps to Reproduce: 1. execute /usr/bin/free -b Actual results: Wrong total count (1'672'607'334) Expected results: Exact total count Additional info: