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.
953016291a
[ the original newlib commit message(s) appear below ] ---------------------------------- newlib patch #1 --- top: refactor 'scale_tics' function for better scaling This patch refactors the 'scale_tics' function to more closely parallel uptime shown on the first line of the summary area. The old logic has been preserved through the header file's new #define SCALE_FORMER provision. However, the former logic was actually a big disaster. These are some potential problems with that old logic: 1. With respect to our time fields top no longer deals solely with cpu time. So, the old limits of '68 weeks' could possibly be insufficient to reflect those times. 2. Given the widths of top's new time fields, the code never got beyond scaling to hours. For example, with a ridiculously large span of 19 years, the scaled result would then be shown as '167832h'. We never reached the days ('6993d') or even the weeks ('999w') equivalents. 3. Similarly, with that 'TIME+' field and a large tics value, results would then appear as 'MMMMMM:SS' rather than the more meaningful 'HH:MM:SS' or days and hours. So henceforth we will adopt these scaling conventions: MMM:SS.hh ... minutes:seconds.hundredths MMM:SS ...... minutes:seconds HH,MM ....... hours,minutes D+H ......... days+hours (with 'd' & 'h' suffixes) D ........... days (with 'd' suffix) W+D ......... weeks+days (with 'w' & 'd' suffixes) W ........... weeks (with 'w' suffix) Note that, unlike our former scaling logic, that 'MMM' portion won't be allowed to grow unconditionally. It's limited (arbitrarily?) to 360 total minutes (6 hours). Additionally, the 'HH' guy will be limited to 96 hours (4 days) while that 'D' limit was set at 14 (2 weeks). Whenever a limit is hit, scaling will advance a level. ---------------------------------- newlib patch #2 --- top: extended 'scale_tics' function for Ctrl-E scaling That normalization of the 'scale_tics' function in the prior commit convinced me that I won't please everyone with my arbitrary choices for the scaling transitions. So, this patch will provide the users with a means for setting their own scaling transition points with a new toggle. Ctrl-E was chosen since the 'e/E' toggles were already present as a means of scaling (albeit memory). [ this toggle will also serve an educational purpose ] [ by allowing one to see all the scaling conventions ] The scaling a user establishes is saved in the rcfile. ---------------------------------- newlib patch #3 --- top: enhanced 'scale_tics' function for Ctrl-E scaling When scale_tics was refactored and then Ctrl-E support added to top, the complete range of scaling values was not visible. Namely, a single 'd' (days) & 'w' (weeks) was never seen with ^E. With this commit they will be. Signed-off-by: Jim Warner <james.warner@comcast.net> |
||
---|---|---|
contrib | ||
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 | ||
Makefile.am | ||
NEWS | ||
pgrep.1 | ||
pgrep.c | ||
pidof.1 | ||
pidof.c | ||
pidwait.1 | ||
pkill.1 | ||
pmap.1 | ||
pmap.c | ||
procio.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.