Added function procps_linux_version() which used to be an
exported integer instead. Also changed the method of obtaining
the linux version (more correctly the os release) to use a specific
procfs entry. This works for both Linux and FreeBSD.
Under a lxc container, the /proc/meminfo 'MemFree' and
'MemAvailable' amounts will be equal, unless memory is
being limited via cgroups in which case 'MemAvailable'
could exceed that for 'MemTotal'. And when a container
has been nested, there exist additional memory quirks.
A program might then display used or available amounts
greater than total memory (assuming unsigned honored),
or negative values (should a signed cast be employed).
This anomaly primarily impacted the top and free pgms.
Thus, two simple sanity checks have been introduced to
avoid any illogical kb_main_available or kb_main_used.
( Busybox top & free also display anomalous although )
( different results when running in a lxc container. )
Reference(s):
https://bugzilla.redhat.com/show_bug.cgi?id=1153817
Signed-off-by: Jim Warner <james.warner@comcast.net>
Let's not report zero for kb_main_available when older
kernels don't have MemAvailable. Instead, if we simply
duplicate the 'free' amount we can avoid all ancillary
problems, such as those involving top's graphing mode.
Reference(s):
http://www.freelists.org/post/procps/kb-main-available-etc,3
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit just ensures recalculation of some amounts
for iterative processes, like top. It also trades some
repeated runtime calls to sysconf for a one time cost.
Reference(s):
http://www.freelists.org/post/procps/systemd-support-to-library,7
. fall-back calculations
commit b779855cf1
Signed-off-by: Jim Warner <james.warner@comcast.net>
The stderr message regarding ELF notes appears on some
systems (openSUSE-13.1 for example) but I have not yet
isolated why. Since at startup we go on to determine a
Hertz value the old fashion way, this patch just turns
off the useless message until the cause is understood.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit adds support for fallback calculation
of the MemAvailable field if not exported by the
kernel. The MemAvailable field appeared in kernel
3.14, but it's possible to calculate it from other
fields since 2.6.27 (splitLRU changes).
This commit adds a new switch -a/--available that
appends a new column called 'available' to the
output. The column displays an estimation
of how much memory is available for starting
new applications, without swapping. Unlike the data
provided by the 'cached' or 'free' fields, this
field takes into account page cache and also that
not all reclaimable memory slabs will be reclaimed
due to items being in use.
The subtraction was marked as reinforcing the misconception,
that memory in the page cache can be considered free.
The Cached value is not a sum of page cache and tmpfs,
as the tmpfs memory lives in the page cache and therefore
it's an inseparable part of it.
tmpfs has become much more widely used since distributions use it for
/tmp (Fedora 18+). In /proc/meminfo, memory used by tmpfs is accounted
into "Cached" (aka "NR_FILE_PAGES",
http://lxr.free-electrons.com/source/mm/shmem.c#L301 ).
The tools just pass it on, so what top, free and vmstat report as
"cached" is the sum of page cache and tmpfs.
free has the extremely useful "-/+ buffers/cache" output. However, now
that tmpfs is accounted into "cached", those numbers are way off once
you have big files in /tmp.
Fortunately, kernel 2.6.32 introduces "Shmem", which makes tmpfs memory
usage accessible from userspace (
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4b02108ac1b3354a22b0d83c684797692efdc395 ).
This patch substracts Shmem from Cached to get the actual page cache
memory. This makes both issues mentioned above disappear. For older
kernels, Shmem is not available (hence zero) and this patch is no-op.
Additionally:
* Update the man pages of free and vmstat to explain what is happening
* Finally drop "MemShared" from the /proc/meminfo parser, it has been
dead for 10+ years and is only causing confusion ( removed in kernel
2.5.54, see
https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/?id=fe04e9451e5a159247cf9f03c615a4273ac0c571 )
vmstat -d or vmstat -p would crash mysteriously under different
circumstances. The problem was eventually tracked down to /sys not
being mounted which meant is_disk() always returned false.
The partition would then be attempted to be linked to a non-existent
disk causing a segfault.
vmstat will now not link to a disk if none exists.
The change in testing will skip those tests when /sys/block doesn't
exist.
Many thanks to Daniel Schepler for his analysis and suggestions.
Bug-Debian: http://bugs.debian.org/736628
Previously the shared memory column was always zero
for 2.6 series kernels (and later) due to the fact,
that the value was taken from the MemShared entry
that disappeared with 2.6 series kernels.
Later a new Shmem entry appeared in the /proc/meminfo
file and the 'shared' column now displays either
the MemShared or the Shmem value (depending on their
presence - the presence is mutually exclusive).
If none of the two entries is exported by the kernel,
then the column is zero.
An unpleasant thing happened when I comitted the shmem support
for the 'free' tool. We already had a merge request from
Adrian Brzezinski in the queue, doing exactly the same.
As Adrian deserves credits, I'm reverting the change
and re-applying with the next commit in order to make
him a part of the project history.
Previously the shared memory column was always zero
for 2.6 series kernels (and later) due to the fact,
that the value was taken from the MemShared entry
that disappeared with 2.6 series kernels.
Later a new Shmem entry appeared in the /proc/meminfo
file and the 'shared' column now displays either
the MemShared or the Shmem value (depending on their
presence - the presence is mutually exclusive).
If none of the two entries is exported by the kernel,
then the column is zero.
It seems in some cases procs_running field of /proc/stat can contain 0 even if vmstat itself is running. At least this can be reproduced on Linux 3.9.3 compiled with BFS scheduler.
Since getstat() decrements value of procs_running by 1, we get overflow:
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 667732 918996 57376 911260 21 30 36 40 98 45 14 82 4 1
4294967295 0 667728 916716 57376 911264 8 0 8 0 1958 3733 28 7 65 1
0 0 667700 915996 57376 911416 24 0 152 0 1735 3600 23 5 71 1
4294967295 0 667700 915872 57376 911392 0 0 0 0 1528 3165 21 4 76 0
Function getbtime() currently makes the assumption that btime==0 equals
btime not being present in /proc/stat. This is not quite accurate, as
timestamp 0 is, in fact, also a valid time (Epoch), and /proc/stat may
report it as such.
We introduce a flag to indicate whether btime was found in /proc/stat.
In this way, btime==0 becomes a valid case, provided /proc/stat
actually reports this as the boot time.
procps can still detect the case of btime actually not being reported
by the kernel.
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
An earlier commit attempted to cleanse our environment
of all useless trailing whitespace. But the effort did
not catch 'empty' lines with a single space before ^J.
This commit hopefully finishes off the earlier effort.
In the meantime, let's pray that contributors' editors
are configured so that such wasted crap is disallowed!
Reference(s):
commit fe75e26ab6
Signed-off-by: Jim Warner <james.warner@comcast.net>
The entire tree's polluted with inappropriate trailing
whitespace. This commit rids our environment of all of
those useless keystrokes. Unfortunately, it sure ain't
a permanent solution and requires every contributor to
instruct their editor(s) to prevent or eliminate them.
Plus it's strongly recommended we all insert something
like what's shown below to our '.gitconfig' file so as
to provide at least some warnings when we try to apply
any patches (git am) that do contain the #@!%& things!
References(s):
~/.gitconfig excerpt ---------------------------------
[core]
whitespace = trailing-space, space-before-tab, blank-at-eof
[apply]
whitespace = warn
--------------------------------- ~/.gitconfig excerpt
Signed-off-by: Jim Warner <james.warner@comcast.net>
The problem is that in ./proc/sysinfo.c uptime(), it is not
considered that the "savelocale" string is overwritten by the
subsequent call to setlocale(). Hence restoring the locale later on
won't work this way. "savelocale" ought to be a copy of the string
pointed to by setlocale()'s return-value.
Bug-Redhat: https://bugzilla.redhat.com/show_bug.cgi?id=548711
Backported-by: Sami Kerola <kerolasa@iki.fi>
There were numerous library memory allocation inconsistencies.
Some were checked for failure and others were not.
All library source modules were modified to utilize the alloc.h
memory rouines which are consistent in dealing with errors.
configure.ac now set to 3.3.1
vmstat -p has not worked for a long time, this applies Debian patch
vmstat_part_format, the details:
Author: Daniel Novotny
Description: The contents of /proc/diskstats have changed since 2.6.25
Changed PATH_MAX to 32 because its missing on hurd
Bug-Redhat: https://bugzilla.redhat.com/show_bug.cgi?id=485243
Bug-Debian: http://bugs.debian.org/588677
Last-Update: 2010-11-17
For the small number of devices that we cannot get Hertz out of ELF
notes but the cpu numbers make sense (ie not kFreeBSD) there is a hack
by using the CPU numbers. The problem is there was 4 numbers, now there
are 7. This fixes the hack by adding all 7 to get a more correct number.
This is from Debian patch sysinfo_7_numbers
Bug-Debian: http://bugs.debian.org/460331
FreeBSD has no good way of finding the Hertz value. ELF notes don't
work, you can't find it in a function and even asm/params.h does
not have it. Lucky for us, it is always 100.
Based upon Debian patch patch sysinfo_kfreebsd_hertz by Petr Salinger
Bug-Debian: http://bugs.debian.org/460331
Caution, 460331 has lots of overlapping bugs all around the Hertz
problem across many arches.
Suppresses a message about elf notes not found on non-Linux systems.
kFreeBSD systems, for one, don't have this so the message appears
every time you run a procps program otherwise.
Based upon Debian patch sysinfo_elfnote by Petr Salinger
Bug-Debian: http://bugs.debian.org/378157
Library changes
readproc
. added support for supplementary groups
. eliminated 2 potential mem leak sources
. shortcut used for multi-threaded str
vectors & ptrs was obsoleted
. freeing of proc_t related dynamic
memory now rests with the library
. standardized/normalized many c comments
sysinfo
. corrected note regarding glibc & cpuinfo
library.map
. made the visible freeproc accessable
Program changes
pmap
. initialized buffer for new readproc i/f
. eliminated now obsolete free() call
ps
. added width aware supgrp support
. initialized buffers for new readproc i/f
. eliminated now obsolete free() calls
top
. added supgrp support as variable width
. eliminated now obsolete free() calls
. expoilted library freeproc function
. corrected -h|v args text & spacing
. updated some c comments
Documentation changes
ps.1
. added supgid and supgrp
top.1
. added supgid and supgrp
. addition of above required renumbering
many fields in section 3a. DESCRIPTIONS
For some reason necessary variable was commented out at June
2003, see commit bellow for details.
commit 5c99a21b72
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Library Changes
. added PROC_EDITCMDLCVT flag
. added an internal (static) fill_cmdline_cvt function:
- reads and "escapes" /proc/#/cmdline
- returns result as a single string in a single vector
- callers are guaranteed a cmdline (no more NULL)
. added vectorize_this_str function, exploited by
fill_cgroup_cvt, fill_cmdline_cvt
. generalized read_cmdline function as read_unvectored, now
exploited by fill_cgroup_cvt, fill_cmdline_cvt, read_cmdline
( cgroup and cmdline no longer need be converted to string )
( vectors before being transformed to final representation )
. fixed bug regarding skipped group numbers (when enabled)
. escape_str made responsible for all single byte translation
with distinction between control chars + other unprintable
. added escaped_copy function for already escaped strings
. reorganized parts of proc_t to restore formatting standards
( displacement changes shouldn't matter with new version # )
. former ZAP_SUSEONLY #define now OOMEM_ENABLE
. added to library.map: escaped_copy; read_cmdline
Top Program Changes
. exploited the new PROC_EDITCMDLCVT provision
. eliminated now obsolete #include "proc/escape.h"
. changed the P_WCH display format if no kernel symbol table
. fixed very old bug in lflgs for out-of-view sort fields
. former ZAP_SUSEONLY #define now OOMEM_ENABLE
Ps Program Changes
. exploited the new PROC_EDITCMDLCVT provision
. exploited the new escaped_copy function
. consolidated pr_args and pr_comm into pr_argcom
Signed-off-by: Jan Görig <jgorig@redhat.com>
Having one constructor depend on another means if the order
is reversed you get a different result.
Patched based on idea by Tom Evans.
Added new code to old_Hertz_hack by Werner Fink <werner@suse.de>
Bug-Debian: http://bugs.debian.org/460331
Bug-Redhat: https://bugzilla.redhat.com/show_bug.cgi?id=632236
Reviewed-by: Jan Görig <jgorig@redhat.com>
Read the time of system boot from /proc/stat (entry: btime) instead
of computing it as the difference between the current time and the
uptime. This is the only way to get a consistent result which won't
possibly change from one run to the next.
The problems with the original code were:
* Both the current time and the uptime are rounded down to the second,
but the system doesn't boot on an integer second value so they do not
tick at the same moment. Thus, the rounding errors can cause a one
second difference from one run to the next.
* We can't read the uptime and the current time at the exact same moment
anyway, so the time difference we compute is bound to be inaccurate.
Bug-Redhat: https://bugzilla.redhat.com/show_bug.cgi?id=222251
Author: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Craig Small <csmall@debian.org>
