After the commit referenced below the potential exists
for a SEGV (resulting from an out-of-bounds Item_table
reference if PROCPS_PIDS_physical_end is encountered).
So this patch eliminates that PROCPS_PIDS_physical_end
as no longer necessary and completes the task of using
PROCPS_PIDS_logical_end as a sole necessary fencepost.
Reference(s):
commit e7585992d9
Without breaking either ABI or API just rearrange some
stuff to provide a little more consistent source file.
[ these were prompted by some work on the <stat> API ]
[ in preparation for him borrowing some of our code. ]
Reference(s):
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the configure option --enable-harden-flags the CFLAGS and
LDFLAGS are manipulated to provide some hardening protection
to the binaries.
psmisc uses these flags on by default with no troubles, however
it doesn't have a library in it either.
References:
https://wiki.debian.org/Hardening
Generalised the library API tests and created a common
test-runner. Instead of copy and pasting the same code in
each time.
First cut of pids API test, for _new so far.
Remove a remnant of this new API's evolution. Here we
no longer fill stacks, rather we reap and select them.
Signed-off-by: Jim Warner <james.warner@comcast.net>
By co-mingling both external/internal identifiers with
actual implementation code, potential future additions
to our API would have been considerably more difficult.
So, this patch will now rely solely on internal/hidden
identifiers serving as fenceposts in validation logic.
And if the following convention is used for new fields
we will maintain that enumerator alphabetic ordering a
a little longer (even though 2 user fields now don't):
. PROCPS_PIDS_XTRA_FOO_A, PROCPS_PIDS_XTRA_FOO_B, etc.
Reference(s):
http://www.freelists.org/post/procps/me-too-newlib,7
Signed-off-by: Jim Warner <james.warner@comcast.net>
Unfortunately, reading that '/proc/sys/kernel/pid_max'
file returns a newline, which we will now account for.
[ also, we should use the existing dedicated buffer ]
Reference(s):
. original 'procps_pid_length' introduction
commit ccb6ae8de1
Signed-off-by: Jim Warner <james.warner@comcast.net>
A difference in behaviour between the sysvinit and procps pidof
was that the procps one would sometimes not find process that
the sysvinit one did.
The difference is that if a space is found in argv[0] then sysvinit
would look at cmd for a match. This isn't perfect and more of a
best guess but does often work.
procps pidof now follows the same "standard". The most obvious
difference is with kde based processes and incoming ssh connections
with sshd.
References:
Commit 3f5b75035e
GitLab issue #4https://gitlab.com/procps-ng/procps/issues/4https://github.com/limingth/sysvinit/blob/master/sysvinit-2.88dsf/src/killall5.c#L800
escaped_copy(): only appears in ps, moved to ps/output.c
escape_strlist() only used in escape.c made static
escape_command() used in library, made internal
procps.h no longer includes escape.h
escape_str() used by library and ps so needs to be exported
definition put into procps.h including the odd define required.
Far from ideal to have it this way, will look at it another time
to have it all in, all out or split nicer so its not in the API;
perhaps a lib/ file?
readproc still had some of the old API hanging around that
was good while we were trying it out, but its time to say
goodbye:
readproc.h removed from public procps.h header file
enum ns_type - not used - removed
get_ns_name() - not defined - removed
get_ns_id() - not defined - removed
PROCTAB proc_t only used internal to library
readproctab() and 2,3 friends not used - removed
proc_data_t was used by readproctab23() - removed
readtask() - not used - removed
read_cmdline() - copy,renamed and made generic - remove original
freeproc() - not used - removed
get_proc_status - not used - removed, however there should be
a new function created that does this. Given a PID return data
about it instead of scanning the entire procfs. Maybe it already does.
Left as internal-to-library only functions:
readproc(), readeither(), look_up_our_self(), openproc(), closeproc()
Updated libprocps.sym to export only what we use.
Rather than importing NORETURN & MALLOC, it feels more
natural to use the native gcc attribute for NORETURN &
eliminate the use of a questionable MALLOC altogether.
Reference(s):
commit ccb6ae8de1
Signed-off-by: Jim Warner <james.warner@comcast.net>
Now that the conditional OOMEM_ENABLE has been removed
and more attention recently paid to the 2 oomem fields
it was revealed that Rc.zero_suppress didn't extend to
them. So this commit will just correct that oversight.
And while we're at it, we'll also extend zero suppress
to that NI (nice value) field, which already should've
had it. Plus we trade those namespaces custom suppress
logic for our now slightly enhanced make_num function.
Reference(s):
. removal of misguided OOMEM_ENABLE
commit 64238730fa
. zero suppression only recently added to namespaces
commit b2853ed117
Signed-off-by: Jim Warner <james.warner@comcast.net>
Now that the conditional OOMEM_ENABLE has been removed
and all users exposed to those 'out of memory' fields,
it's about time we added them to the top man document.
But before doing so, it's long past time that they are
normalized to at last remedy this kind of foolishness:
. excessive width on that oomem score itself (8 vs. 4)
. some potentially confusing names inherited from suse
Reference(s):
. removal of misguided OOMEM_ENABLE
commit 64238730fa
Signed-off-by: Jim Warner <james.warner@comcast.net>
Now that the conditional OOMEM_ENABLE has been removed
and, after reviewing current library support, it turns
out we've been using a deprecated /proc/<pid>/oom_adj.
What we should use instead is that more recent tunable
/proc/<pid>/oom_score_adj. This new field will provide
a range of -1000 thru +1000 (former was -17 thru +15).
Reference(s):
. removal of misguided OOMEM_ENABLE
commit 64238730fa
. linux, partial oom_adj revert (Nov, 2012)
commit fa0cbbf145aabbf29c6f28f8a11935c0b0fd86fc
. linux, removal oom_adj (Oct, 2012)
commit 01dc52ebdf472f77cca623ca693ca24cfc0f1bbe
Signed-off-by: Jim Warner <james.warner@comcast.net>
The includes used to define a lot of things a library include
should not. It was also a bit messy what was exposed in the library
and what was not.
get_pid_digits -> procps_pid_length and exported correctly
MALLOC attribute move into relevant .c files
NORETURN attribute moved to relevant .c, not used in library
PURE attribute removed, it wasn't used
KLONG/KLF/STRTOUKL were fixed for long, so now just use long
HIDDEN attribute removed. It was for 3 functions. The PROCPS_EXPORT
seems to do the same (opposite) thing.
likely/unlikely removed from most places, its highly debateable
this does anything useful as CPUs have gotten smarter about branches.
Re-arranged the includes, ALL external programs should just #include
<proc/procps.h> then proc/procps.h includes headers for files that
have exported functions. procps.h and the headers it includes should
not use items that are not exportable (e.g. hidden functions or
macros) they go in procps-private.h
Getting the manual page for procps_linux_version(3) fixed up so
it follows the man-pages(7) and other standards.
Added lgpl license to file, so its the same as the code.
If SELINUX is enabled but the machine is using another MAC system
(like apparmor), ps will fallback to just parsing
"/proc/%d/attr/current", otherwise the label/context would not
be properly displayed in that case.
References:
https://bugs.debian.org/786956
Signed-off-by: Craig Small <csmall@enc.com.au>
Multiple scanf()s use the GNU-permitted %Lu. This is not supported in
other libraries and isn't to the POSIX specification. The L modifier
is only used for floats in POSIX.
Replacing %Lu with %llu is the same for GNU libc (scanf(3) says as much)
but means other libraries will work fine.
From master commit da715e3
References:
http://pubs.opengroup.org/onlinepubs/009695399/functions/fscanf.html
Beginning with linux-4.5, the following new fields are
being added under that /proc/<pid>/status pseudo file:
. RssAnon - size of resident anonymous memory
. RssFile - size of resident file mappings
. RssShmem - size of resident shared memory
This patch just represents the initial library and top
support, sharing a commit message with 2 more patches.
p.s. locked resident memory support was also added but
isn't directly related to the kernel 4.5 enhancements.
Reference(s):
commit 1f8e41d019
Signed-off-by: Jim Warner <james.warner@comcast.net>
Beginning with linux-4.5, the following new fields are
being added under that /proc/<pid>/status pseudo file:
. RssAnon - size of resident anonymous memory
. RssFile - size of resident file mappings
. RssShmem - size of resident shared memory
This patch just represents the initial library and top
support, sharing a commit message with 2 more patches.
p.s. locked resident memory support was also added but
isn't directly related to the kernel 4.5 enhancements.
Reference(s):
commit 1f8e41d019
Signed-off-by: Jim Warner <james.warner@comcast.net>
Beginning with linux-4.5, the following new fields are
being added under that /proc/<pid>/status pseudo file:
. RssAnon - size of resident anonymous memory
. RssFile - size of resident file mappings
. RssShmem - size of resident shared memory
This patch just represents the initial library and top
support, sharing a commit message with 2 more patches.
p.s. locked resident memory support was also added but
isn't directly related to the kernel 4.5 enhancements.
Reference(s):
commit 1f8e41d019
Signed-off-by: Jim Warner <james.warner@comcast.net>
If the mapping descriptor is longer than 128 chars, the last parsed
character won't be a newline even if the current buffer contains it a
bit further than that. The current code always interprets it as a short
fgets() read instead, and thus keeps calling fgets() until it gets a
newline, dropping valid lines and failing with the following error:
pmap: ERROR: inconsistent detail field in smaps file, line:
Rss: 212 kB
[ patch has been adapted expressly for newlib branch ]
In response to Issue #21, the commit referred to below
provided some much needed improvements and corrections
to topic `3a. DESCRIPTIONS of Fields' in the man page.
However, it assumed a reader possessed much background
knowledge that may not, in truth, actually be present.
So without, hopefully, insulting anyone's intelligence
this patch offers an expanded discussion of some terms
and concepts within a separate section under OVERVIEW.
[ plus it affords an opportunity to incorporate that ]
[ extremely useful table from Florent Bruneau's post ]
Reference(s):
commit 6a36bd7afdhttps://techtalk.intersec.com/2013/07/memory-part-1-memory-types/
Signed-off-by: Jim Warner <james.warner@comcast.net>
Due to quirks in kernel memory management plus limited
information available from /proc/<pid>/status & statm,
some of the top resident memory fields were capable of
exceeding available physical memory. So this commit is
a bit of a band-aid until the kernel has been changed.
Such a change appears to be on the horizon in the form
of three new fields to be added to /proc/<pid>/status.
While not preventing 'resident' memory from apparently
exceeding physical memory, the new fields will help to
clarify any such contingency, if/when we exploit them.
Reference(s):
. original post by Samuel Thibault
https://gitlab.com/procps-ng/procps/issues/21
. informative memory analysis
https://techtalk.intersec.com/2013/07/memory-part-1-memory-types/https://techtalk.intersec.com/2013/07/memory-part-2-understanding-process-memory/
. kernel changes to /proc/<pid>/status
commit 8cee852ec53fb530f10ccabf1596734209ae336b
commit eca56ff906bdd0239485e8b47154a6e73dd9a2f3
Signed-off-by: Jim Warner <james.warner@comcast.net>
The commit referenced below claims to disable vertical
scrolling when idle tasks weren't being shown. However
it really addresses only a point in time when that 'i'
toggle is keyed. Left untouched were the up/down keys.
So this commit will simply finish the job of disabling
vertical scrolling whenever tasks which have used some
CPU are the only ones which are currently being shown.
Reference(s):
commit c07f6c5e6d
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit is just a cleanup of some extraneous cruft
left after the newlib migrations and summarized below:
. whack the 2nd line of what was an eliminated comment
. eliminated reference to NUM_NS and thus that need to
include the otherwise defunct 'readproc.h' header file
. reference to Frame_maxtask made properly generalized
. all former sort support #define's are now eliminated
Signed-off-by: Jim Warner <james.warner@comcast.net>
Summarized below, miscellany addressed in this commit:
. deleted extraneous newline(s) for consistent spacing
Signed-off-by: Jim Warner <james.warner@comcast.net>
Historically LFS mattered only to open/read large files. A few programs
here use open/seek, but not generally on files that are large. However,
LFS also applies to stat which procps does in a bunch of places -- some
filesystems have 64bit inodes and attempts to do a 32bit stat will throw
an error.
Enable transparent LFS everywhere to avoid this.
There is a need in some utilities to have a way of accepting both
types of decimal points "." and ",". The only way seems to be to
rebuild strtod().
This new function will accept "123.456" and "123,456" as 123.456
and considers them the same number. It means we lose thousands
separator, but this is rarely used.
test scripts are added to check the function returns the proper
values. There was simpler predecessor that got stuck on negative
0 or -0.123 which these tests flushed out.
References:
Commit 99fa7f removed watch crashing from having the null ANSI
sequence. However it just ignored that sequence instead of fixing it.
This change correctly checks buf (not undefined endptr) and sends
the reset attribute if found.
Closes: #12
It is documented behavior that when certain other keys
are active, sorts column highlighting will temporarily
be disabled. Among those keys is the 'L' (locate/find)
provision. The equals ('=') key can be used to restore
column highlighting by resetting other keys, except 1.
When a locate/find is active, the '=' key will have no
effect on 'x' column highlighting, which still remains
disabled. Further, when 'L' is active an 'x' keystroke
is processed changing the state of column highlighting
but without any visual clue (since it's yet disabled).
So this commit just extends the '=' key to embrace 'L'
processing resets, just like other highlight disabling
keys while avoiding 'x' state changes if approproiate.
Signed-off-by: Jim Warner <james.warner@comcast.net>
