Command line and full screen utilities for browsing procfs, a "pseudo" file system dynamically generated by Linux to provide information about the status of entries in its process table.
40883a0b85
Some parts of our newlib implementation are the result of functions which have been propagated from module to module. In particular, those 'cleanup_stacks' routines are all similar & likely originated in the <pids> api. In that interface there was a need to free dynamically acquired memory before the result structure was reused to satisfy subsequent 'get', 'select' or 'reap' calls. This, in turn, led to a concept of 'dirty' stacks with the need to call one of two 'cleanup_stack' functions. None of the remaining interfaces deal with such memory yet they each had their own 'cleanup_stack' functions. Those functions were responsible for resetting each of the result unions to zero, excluding any 'noop' items. The bottom line is that for all interfaces, repetitive calls would require iterating through the stack(s) two separate times: once to 'cleanup' another to 'assign'. With this commit we will reduce iterations to just the 'assign' routine. A reset to zero will be accomplished in the 'extra' item set routine (which is the only one actually requiring any reset). All other items will be reinitialized automatically by a new current set value or upon reallocation when an items compliment changes. In the <pids> interface, any freeing of dynamic memory could have been accomplished by adding that 'freefunc' check to the 'assign' function. However, that requires an Item_table test with every item. Instead, we'll now satisfy such needs as the very first step in those set functions responsible for dynamically acquired memory. [ the <pids> api retains 2 'cleanup_stack' functions ] [ to accommodate stack(s) 'reset' & to serve 'unref' ] Lastly, all the 'itemize_stack' functions were tweaked by eliminating an unnecessary initialization of result unions. That objective was already accomplished by the calloc() in a 'stacks_alloc' function or the remaining 'cleanup_stack' routine found in the <pids> 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.