mirror of
https://gitlab.com/procps-ng/procps.git
synced 2024-11-30 21:44:05 +08:00
abc71a46ad
This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net> |
||
---|---|---|
contrib | ||
doc | ||
Documentation | ||
include | ||
lib | ||
man-po | ||
misc | ||
po | ||
proc | ||
ps | ||
testsuite | ||
top | ||
.gitignore | ||
.gitlab-ci.yml | ||
AUTHORS | ||
autogen.sh | ||
ChangeLog | ||
configure.ac | ||
COPYING | ||
COPYING.LIB | ||
create-man-pot.sh | ||
free.1 | ||
free.c | ||
INSTALL.md | ||
kill.1 | ||
kill.c | ||
Makefile.am | ||
NEWS | ||
pgrep.1 | ||
pgrep.c | ||
pidof.1 | ||
pidof.c | ||
pkill.1 | ||
pmap.1 | ||
pmap.c | ||
pwdx.1 | ||
pwdx.c | ||
README.md | ||
skill.1 | ||
skill.c | ||
slabtop.1 | ||
slabtop.c | ||
snice.1 | ||
sysctl.8 | ||
sysctl.c | ||
sysctl.conf | ||
sysctl.conf.5 | ||
tload.1 | ||
tload.c | ||
translate-man.sh | ||
uptime.1 | ||
uptime.c | ||
vmstat.8 | ||
vmstat.c | ||
w.1 | ||
w.c | ||
watch.1 | ||
watch.c |
procps
procps is a set of command line and full-screen utilities that provide information out of the pseudo-filesystem most commonly located at /proc. This filesystem provides a simple interface to the kernel data structures. The programs of procps generally concentrate on the structures that describe the processess running on the system.
The following programs are found in procps:
- free - Report the amount of free and used memory in the system
- kill - Send a signal to a process based on PID
- pgrep - List processes based on name or other attributes
- pkill - Send a signal to a process based on name or other attributes
- pmap - Report memory map of a process
- ps - Report information of processes
- pwdx - Report current directory of a process
- skill - Obsolete version of pgrep/pkill
- slabtop - Display kernel slab cache information in real time
- snice - Renice a process
- sysctl - Read or Write kernel parameters at run-time
- tload - Graphical representation of system load average
- top - Dynamic real-time view of running processes
- uptime - Display how long the system has been running
- vmstat - Report virtual memory statistics
- w - Report logged in users and what they are doing
- watch - Execute a program periodically, showing output fullscreen
Reporting Bugs
There are a few ways of reporting bugs or feature requests:
- Your distributions bug reporter. If you are using a distribution your first port of call is their bug tracker. This is because each distribution has their own patches and way of dealing with bugs. Also bug reporting often does not need any subscription to websites.
- GitLab Issues - To the left of this page is the issue tracker. You can report bugs here.
- Email list - We have an email list (see below) where you can report bugs. The problem with this method is bug reports often get lost and cannot be tracked. This is especially a big problem when its something that will take time to resolve.
If you need to report bugs, there is more details on the Bug Reporting page.
Email List
The email list for the developers and users of procps is found at http://www.freelists.org/archive/procps/ This email list discusses the development of procps and is used by distributions to also forward or discuss bugs.