20e44569f5
With openSUSE's tumbleweed release of procps-ng-4.0.0, their source rpm contained a questionable patch. It is ostensibly devoted to increasing the accuracy for %cpu calculations in the ps program. However, in my opinion it goes too far and is quite flawed for these reasons: 1. Six separate files were impacted instead of just 1. 2. While ps was the object, libproc-2 was changed too. 3. A header file's alphabetic item order was violated. 4. The library API and ABI were altered unnecessarily. It should be noted that all the <pids> TIME items were made 'real' when representing seconds so that they can be converted into jiffies/tics if multiplied by hertz. Thus, there was absolutely no justification for adding a new PIDS_TICS_ELAPSED ull_int item to the interface. As an example, assuming a hertz value of 100, there is enough capacity in all of those 'TIME' seconds to hold nearly 3 million years worth of tics without a loss of precision whenever they are changed back into jiffies. [ that's nine quadrillion seven trillion one hundred ] [ ninety-nine billion two hundred fifty-four million ] [ seven hundred forty thousand nine hundred ninety + ] [ one! or more concisely, as: 9,007,199,254,740,991. ] So, any need for increased accuracy in that ps program can be realized within the single output.c file alone. That's what will be accomplished with this new commit. And for any doubters here's a 'double' capacity proof: beg ------ 9007199254740991.000000000000000000000 tic| d /= 100, 90071992547409.90625000000000000000000 sec d /= 60, 1501199875790.165039062500000000000000 min d /= 60, 25019997929.83608245849609375000000000 hrs d /= 24, 1042499913.743170142173767089843750000 day d /= 7, 148928559.1061671674251556396484375000 wks d /= 52, 2864010.752041676081717014312744140625 yrs d *= 52, 148928559.1061671674251556396484375000 wks d *= 7, 1042499913.743170142173767089843750000 day d *= 24, 25019997929.83608245849609375000000000 hrs d *= 60, 1501199875790.165039062500000000000000 min d *= 60, 90071992547409.90625000000000000000000 sec d *= 100, 9007199254740991.000000000000000000000 tic end ------ 9007199254740991.000000000000000000000 " | [ who knows, maybe we'll even convince openSUSE that ] [ the original sledgehammer 'dif' should be dropped. ] Reference(s): . openSUSE equivalent: 'procps-ng-4.0.0-accuracy.dif' Signed-off-by: Jim Warner <james.warner@comcast.net>
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 distribution's 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.