1. 16 Mar, 2017 6 commits
    • top: just update all of the copyright dates in sources · 810e1d38
      [ this patch has been adapted from the master branch ]
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: by default, show cmd line vs. cmd name at startup · 835ee677
      All of top's display was designed to fit into an 80x24
      terminal. This includes the help screens plus both the
      Summary and Task Areas, assuming no saved config file.
      
      With release 3.3.10, the startup defaults were changed
      assuming ./configure --disable-modern-top wasn't used.
      This was done in the hope of introducing some users to
      unknown capabilities such as colors, forest view, etc.
      
      The purpose of this commit is to coax a few more users
      into possibly exploring another capability: scrolling.
      We do so by tweaking the default startup display so as
      to show full command lines. Now, when things no longer
      fit in 80x24, horizontal scrolling might be exploited.
      
      [ of course, this can be reversed with the -c switch ]
      
      [ this patch has been adapted from the master branch ]
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: provide -1 command line switch as 'Cpu(s)' toggle · 5e708c5d
      If built without ./configure --disable-modern-top, the
      program displays each cpu individually providing there
      is sufficient vertical screen real estate. For massive
      SMP environments this will necessitate use of a config
      file where the cpu summary toggle ('1') could be saved
      via the 'W' command. But, an rcfile may not be viable.
      
      So this commit introduces a '1' command line switch to
      emulate exactly the effects of the interactive toggle.
      
      And since it is our first numeric switch some existing
      parsing logic had to be changed slightly. Such changes
      are, in truth, an improvement. For example, instead of
      seeing "inappropriate '2'" with ./top -2 we'll now see
      the vastly more appropriate error "unknown option '2'.
      
      References(s):
      #55
      
      [ this patch has been adapted from the master branch ]
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: provide -E command line switch for memory scaling · b2bd6540
      In their 3.2.7 version of top, Redhat introduced an -M
      switch to automatically scale Summary Area memory data
      to avoid truncation (and the resulting '+' indicator).
      
      The procps-ng top does not employ suffixes with memory
      data nor does it allow for different scaling with each
      separate value. Rather, scaling appears at line start.
      
      If built without ./configure --disable-modern-top, the
      Summary Area memory will be scaled at GiB which should
      lessen chance of truncation. Otherwise KiB was used to
      reflect such memory, increasing the truncation chance.
      
      And while 'W' can be used to preserve some appropriate
      scaling value, there are arguments against such rcfile
      approaches as cited in the issue and bug report below.
      
      So this commit will bump the Summary Area memory scale
      factor from KiB to MiB when using --disable-modern-top
      as a concession to that Redhat bug report noted below.
      
      And it also introduces a new command line switch which
      can force any desired scaling regardless of the rcfile
      or which ./configure option might have been specified.
      
      [ for top's help text we'll show 'E' as if it were a ]
      [ switch without arguments in order to keep the help ]
      [ text displayable without wrap in an 80x24 terminal ]
      
      [ the man page, however, will show all k-e arguments ]
      
      Reference(s):
      #53
      https://bugzilla.redhat.com/show_bug.cgi?id=1034466
      
      [ this patch has been adapted from the master branch ]
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: show fewer decimal places for memory (by default) · f318be46
      After much reflection I've come to the conclusion that
      displaying 3 decimal places (usually) when memory data
      had been scaled is no longer optimal with today's ever
      increasing amounts. And given that not all task memory
      fields are the same widths, inconsistencies can easily
      arise as illustrated and discussed in the issue below.
      
      Instead of unilaterally reducing the number of decimal
      places, this commit will sneak in such a change via an
      existing configure option that was very likely unused.
      
      The former 'disable-wide-memory' option has now become
      'enable-wide-memory', which can be used if the current
      behavior (3 decimal places) is preferred. Without that
      option, whenever memory is scaled beyond KiB, just one
      decimal place will be shown in Summary and Task areas.
      
      And Task area field width will no longer be changed by
      this revised configure option. Instead, all such field
      widths will now be fixed at the former maximum values.
      
      Reference(s):
      #50
      
      [ this patch has been adapted from the master branch ]
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: correct alphabetic ordering with some enumerators · 7468e229
      [ this patch has been adapted from the master branch ]
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
  2. 04 Feb, 2017 4 commits
    • pkill: Return 0 if successfully killed process · ff05573f
      Original report:
      When trying kill a process with insufficient privileges (see blow),
      pkill displays the error message “... failed: Operation not permitted”,
      but returns 0. Surely it should return 3?
      
      $ pkill syslogd ; echo $?
      pkill: killing pid 373 failed: Operation not permitted
      0
      
      Return value 0 means one of more things matched. For a pgrep (which
      shares code with pkill) this makes sense, there was a match. It seems
      wrong for pkill to return 0 when it in fact could not do what you told
      it to.  However return value 3 means a fatal error and it's not fatal.
      
      Looking at other programs when trying to kill things it cannot kill.
      shell kill returns 1, procps kill returns 1, killall returns 1, skill
      returns 0 (and says it was successful!, ah well poor old skill)
      
      The consensus seems to be that you return 1 if you cannot kill it, even
      if you found it. In other words the return value for both not found and
      not able to kill it is the same.
      
      pkill only returns 0 if something was killed. This means we found a
      match AND the kill() system call worked too.
      
      References:
       https://bugs.debian.org/852758
      
      Signed-off-by: Craig Small <csmall@enc.com.au>
      Craig Small committed
    • NEWS: Very minor typo fixed · 1f094f51
      Signed-off-by: Craig Small <csmall@enc.com.au>
      Craig Small committed
    • NEWS: updated with the two most recent program changes · a2d2b89c
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: adapt the master branch XDG specification support · a81a74a1
      This patch adapts a master branch commit to our newlib
      branch. Shown below was that original commit msg text.
      
      ------------------------------------------------------
      top: Add unobtrusive XDG support
      
      By default the file HOME/.toprc will be prefered.  This ensures there
      should be minimal breakage even if this file is later created by some
      other means.  Otherwise we will follow the new behaviour described by
      the XDG Base Directory Specification:
      
      If the XDG_CONFIG_HOME environment variable is available we will attempt
      to use this as XDG_CONFIG_HOME/procps/toprc otherwise we will fall-back
      to HOME/.config/procps/toprc instead.
      
      Signed-off-by: Earnestly <zibeon@gmail.com>
      ------------------------------------------------------
      
      Reference(s):
      . master branch original
      commit 0a0f7d60e309c13c8a399bc2187bed6e3e156b43
      . discussion thread
      !38
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
  3. 26 Jan, 2017 1 commit
  4. 04 Jan, 2017 5 commits
    • documentation: Update pids manual pages · 2598e9f2
      Updated the full suite of manual pages for the procps_pids_*
      functions. The only one missing is procps_pids_get which
      may not be required.
      Craig Small committed
    • library <stat>: input file buffer size must be dynamic · ea930f6f
      Since its introduction, our evolved /proc/stat API has
      relied on a static buffer of 8192 bytes. This approach
      is probably Ok for other /proc files but it would only
      accommodate around 100 processors. If such a threshold
      were exceeded then this interface could never succeed.
      
      Now days 100 processors doesn't seem at all excessive.
      
      So this commit trades that static buffer for a dynamic
      self-tuning one. And since so much former top CPU code
      was already rolled into this module, we just stole the
      already proven top dynamic buffer management code too.
      
      [ this also meant switching low level unbuffered I/O ]
      [ calls to standard library buffered I/O calls. that ]
      [ is exactly what <slabinfo> and <diskstats> employ. ]
      
      Reference(s):
      . 1st gen readstat introduction
      commit a410e236
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • library <stat>: improve response to cpu offline/online · 282ee362
      With the addition of those new derived SUM values, any
      CPUs taken offline or brought online would distort the
      historical (delta) results.  So this patch just forces
      a history reset when such transitions are encountered.
      
      Reference(s):
      . derived SUM provisions introduced
      commit 2c86c498
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • library <slabinfo>: make read function name consistent · f82ac70e
      For each of those interfaces employing a priming read,
      all the other 'read' functions begin with the module's
      name except this guy which began with 'read_slabinfo'.
      
      Now, they'll all begin with their module name then end
      the same with a '_read_failed' boolean hinting suffix.
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • library: eliminate distorted history 1st time switches · e524e481
      Upon reflection, at the point where the 'priming read'
      was introduced, any possibility of history distortions
      was also eliminated.  This was true because all of the
      'old' (zeroed) data will have been replaced with 'new'
      data whenever a user finally calls get, select & reap.
      
      Thus, any DELTA values will automatically reflect that
      interval between 'new' and subsequent retrieval calls.
      
      [ diskstats didn't actually employ a 1st time switch ]
      [ like the others so we have changed a comment only. ]
      [ but that module will retain something similar used ]
      [ inside node_update whenever a new node is created. ]
      
      Reference(s):
      . priming read added to slabinfo
      commit 5d5a52a3
      . priming read added to diskstats
      commit ecd64f44
      . priming read added to meminfo, stat, vmstat
      commit 1a2b62c7
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
  5. 03 Jan, 2017 4 commits
    • top: exploits several <stat> new category calculations · 904f4c3b
      This commit just exploits those new library provisions
      for tic categories, introduced in the preceding patch,
      which had been prompted by the issue referenced below.
      
      [ ok it also corrects the top graph for system usage ]
      [ since this turkey failed to include tics for these ]
      [ two interrupts: STAT_TIC_IRQ and STAT_TIC_SOFTIRQ. ]
      
      Reference(s):
      #48
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • library <stat>: standardized new category calculations · 2c86c498
      This commit arose out of the discussion (and research)
      surrounding the issue cited below. It is an attempt to
      consolidate and standardize the calculation of jiffies
      categories (e.g. 'idle', 'busy', etc.) once & for all.
      
      Also included is the enum STAT_TIC_NUM_CONTRIBUTORS in
      case anyone, in the future, decides to calculate usage
      based upon elapsed time * Hz (like top does in process
      level %CPU stats). In such an event, a total number of
      CPUs or NUMA Nodes would be needed for proper scaling.
      
      Reference(s):
      #48
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • library: ensure 'namespace' types treated consistently · 12e070dd
      Unlike the ps kludge under the master branch to ensure
      that namespaces appear the same under both 32 & 64-bit
      models, this newlib branch already used a proper type.
      
      However source data still carried the original type as
      'signed long' versus that more proper 'unsigned long'.
      
      So, this patch makes sources & destinations identical.
      
      Reference(s):
      . master branch ps kludge
      commit c41c614b
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • ps: finish purging those references to PIDS_WCHAN_ADDR · 66e8e272
      Aw shucks, not all support for this defunct enumerator
      was removed via the commits shown below (but, is now).
      
      [ what remained were just variables named after that ]
      [ deprecated/deleted enumerator, but still & all ... ]
      
      [ plus, i have left the doc/libproc.3 file untouched ]
      [ since it already appears badly out of date anyway! ]
      
      Reference(s):
      . ps references partially purged
      commit 66c4024d
      . enumerator purged from library
      commit 91207560
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
  6. 07 Dec, 2016 5 commits
  7. 21 Nov, 2016 1 commit
  8. 15 Oct, 2016 5 commits
    • top: tweak some stuff relating to non-displayed fields · f0064ac1
      In the commit referenced below, in addition to several
      tweaks to comments, 3 fields were no longer assured of
      being present in the results stacks. However, 2 of the
      3 fields might, in fact, be required even if they were
      not currently being displayed in any of the 4 windows.
      
      The PIDS_CMD is used in two separate 'Inspect' headers
      ('Y' command) and the PIDS_ID_EUID is required if that
      'User Filter' ('u' or 'U' command) was being employed.
      
      That latter field's inclusion will be made conditional
      but the former field must be unconditionally included.
      
      ( for old top, PIDS_CMD would have always been there )
      
      Reference(s):
      commit 4e4debda
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • ps: respond to loss of that PIDS_WCHAN_ADDR enumerator · 66c4024d
      No longer will ps print nwchan as 'ffffff', '-' or '1'
      since the proc/PID/stat wchan field didn't represent a
      real address anyway. Rather, the field will henceforth
      output a dash ('-'), the ps customary 'not available'.
      
      That man document was also tweaked to better represent
      actual behavior. An asterisk ('*') was never shown for
      threaded tasks and that dash ('-') usually didn't mean
      running tasks (sometimes associated with permissions).
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • library <stat>: remove that PIDS_WCHAN_ADDR enumerator · 91207560
      Removing the Item_table 'stat' oldflags for WCHAN_ADDR
      was wrong since that 'stat' field is not a constant 0.
      Rather, it could assume these 3 values: -1, 0, and +1.
      
      I have not been able to pin down a '-1' result, but it
      probably means some sort of permission error (-EPERM).
      
      The '1' or '0' values were supposed to distinguish the
      tasks that were or were not blocked (whether there was
      a wchan address). However, in practice there is little
      correlation between those values and availability of a
      kernel symbol in /proc/$$/wchan (perhaps due to race).
      
      Anyway, the real point is that a 'stat' wchan does not
      now intentionally contain an address. Thus, outputting
      'ffffff', '-' or '1' in programs like ps is senseless.
      
      So this patch just eliminates PIDS_WCHAN_ADDR from our
      item enumerators leaving only the PIDS_WCHAN_NAME guy.
      Now the new library can't be blamed for bad addresses!
      
      Reference(s):
      . removed Item_table 'oldflags'
      commit c4aa6c0a
      . linux removal of wchan addresses
      commit b2f73922d119686323f14fbbe46587f863852328
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: make that 'forest view' just a tad more efficient · f3ec7f00
      It makes no sense to begin our tracked nested level at
      '1' then later require a '1' to be subtracted from the
      level as artwork and indentation is added for display.
      
      By beginning such tracked levels at zero, we can avoid
      the need to adjust it & use it directly in a snprintf.
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • top: just cosmetic changes, absolutely no code altered · 7730bcf5
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
  9. 09 Oct, 2016 4 commits
  10. 25 Sep, 2016 2 commits
    • library <stat>: added overlooked numa guest tic counts · 9d1f6cb4
      When this module was upgraded to 3rd generation in the
      patch referenced below, numa node support was migrated
      from the top program into newlib. The 'guest_nice' and
      'guest' tics were overlooked as top did not need them.
      
      So, this commit corrects that oversight and achieves a
      proper symmetry between the cpu & numa jiffies counts.
      
      Reference(s):
      . 3rd gen redesign, numa support imported
      commit abc71a46
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • misc: remove some newly introduced trailing whitespace · fe4a237b
      Maybe some folks still need a few .gitconfig tweaks to
      catch the trailing whitespace errors a little earlier.
      
      Or, at the least, after a local commit they should do:
      $ git diff HEAD~1
      
      [ and then check if git marks any with his red blobs ]
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
  11. 21 Sep, 2016 3 commits
    • library: add priming read at 'new' time <most modules> · 1a2b62c7
      A priming read at 'new' time in that <slabinfo> module
      was important so that permission problems are detected
      early. Plus, it also had the potential of making delta
      values valid when 'get' or 'select' were first called.
      
      It is for that latter reason that such a read was also
      incorporated in the <diskstats> module 'new' function.
      No other module, however, employed such priming reads.
      
      This patch just brings those potential benefits to all
      of our other newlib modules with the exception of that
      <pids> guy. That module is, of necessity, sufficiently
      different from those others to justify such exclusion.
      
      Not only are there precious few DELTA enums in <pids>,
      but the costs of a priming read would be much greater.
      
      [ otherwise, these newly added priming reads have no ]
      [ measurable negative impact on performance/timings. ]
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • library: summary name now more descriptive, <slabinfo> · 5197fa0a
      The <slabinfo> header provides 3 groups of enumerators
      with prefixes of SLABINFO, SLABS & SLABNODE. The first
      is strictly user oriented & isn't supported internally
      by any structure. The other two, however, have structs
      associated with 'em but, unfortunately, 1 is misnamed.
      
      The 'struct slabs_node' is associated with 'nodes' and
      supports the enumerators with the SLABNODE prefix. But
      the 'struct slabs_hist' was associated with 'hist' yet
      supports those enumerators with just the SLABS prefix.
      
      We do not care very much what some structure is called
      but we do care about an identifier used manipulate it.
      
      This patch will trade the 'hist' identifier associated
      with 'struct slabs_hist' for a more congruous 'slabs'.
      
      [ it's awful when the author can't remember what the ]
      [ true meaning of an identifier is after creating it ]
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed
    • library: improve support of dynamic numa nodes, <stat> · eeeba3e6
      If, in fact, numa nodes are dynamic (like that current
      total of on-line cpus) the existing logic was lacking.
      It included an early return before checking the total.
      
      So, this commit ensures that the nodes total is always
      set or updated consistently in only a single function.
      There's no need to set it at the time 'new' is called.
      
      [ and since under our existing code this nodes total ]
      [ could never possibly have been zero, the erroneous ]
      [ test (with the early return) has now been whacked! ]
      
      Signed-off-by: Jim Warner <james.warner@comcast.net>
      jim warner committed