As stated in the previous commit, option '-J' was introduced by commit
"Add -J to filter by matching jail IDs and names."
(13767130c7, r265229), which unfortunately talked about '-J'
being a filter while actually implementing it as a regular selection
option which adds to the processes to display.
The manual page's formulation hinted more at '-J' being a filter, which
it is not, or could be just considered ambiguous, because of the
presence of the "only" word. Consequently, remove it and reformulate.
Reviewed by: ziaee, dch
MFC after: 1 day
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D50194
(cherry picked from commit cbda1aea6532697247bcca6e59d45775857c35e2)
(cherry picked from commit 1586fd84fbdab2e2ec205ca717c69946805f2ba0)
Approved by: re (cperciva)
This is what POSIX mandates for option '-U' and arguably the behavior
that most users actually need in most cases. Before, '-U' would select
processes by their effective user IDs (which is the behavior mandated by
POSIX for option '-u').
Matching by real user IDs allows to list all processes belonging to the
passed users, including those temporarily having a different effective
user ID, which can happen if launched by a setuid executable or if using
some credentials-changing facility (such as seteuid() for root processes
or mac_do(4)/setcred(2)). Conversely, processes temporarily assuming
the identity of some of the passed users will not be listed anymore
(they do not "belong" to these users).
This change also makes '-U' consistent with '-G', the latter already
matching on real group IDs.
While here, remove the (non-compiled) code for tentative option '-R' as
its proposed behavior was the one established here for '-U'. Also, move
the compiled-out old code for '-U' under '-u' for reference, as this is
what the latter should do according to POSIX, even if it seems unlikely
we will want to change the behavior of '-u'.
Reviewed by: manpages (ziaee)
MFC after: 3 days
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49622 (code)
Differential Revision: https://reviews.freebsd.org/D49623 (manual page)
(cherry picked from commit 995b690d1398044dc9d85a6d86ec550cda30b2ac)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49621
(cherry picked from commit 2d7f70975bd8146f36b35477a8a1be490a0afc95)
This puts our ps(1) in conformance with POSIX.
While here, replace ad-hoc initialization of 'uidlist' with a call to
expand_list().
***
Review of the ps(1) implementations in other BSDs, illumos, and Linux's
procps shows they already behave as prescribed by POSIX.
Previously, we would match processes with their effective user ID but
using our real user ID. While the real user ID is meant as the real
identity of a process, and is used, e.g., to perform accounting or be
permitted to send signals to specific targets, selecting processes to
display is arguably more akin to a kind of (advisory) access control.
ps(1) is not installed setuid, so normally the real and effective user
IDs of ps processes are the same. This may however not be the case when
ps(1) is launched by another setuid executable, and the launching
process may then logically expect that ps(1) lists the processes
corresponding to its effective UID.
MFC after: 3 days
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49619 (code)
Differential Revision: https://reviews.freebsd.org/D49620 (manual page)
(cherry picked from commit 1aabbb25c9f9c4372fd68621f8cabdc10b665527)
When combined with other options affecting the selection of processes,
except for '-X' and '-x', option '-a' would have no effect (and '-A'
would reduce to just '-x'). This was in contradiction with the rule
applying to all other selection options stating that one process is
listed as soon as any of these options has been specified and selects
it, which is both mandated by POSIX and arguably a natural expectation.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49617 (code)
Differential Revision: https://reviews.freebsd.org/D49618 (manual page)
(cherry picked from commit 93a94ce731a89b5643021b486da599e7963da232)
The ps(1) display's list of columns is now first built without taking
into account the '-O' options. In a second step, all columns passed via
'-O' are finally inserted after the built-so-far display's first PID
column (if it exists, else at start), in their order of appearance as
arguments to the '-O' options.
This new two-step procedure suppresses the following undesirable
behaviors:
- '-O' used to insert the columns of the default display even if the
user also passed other options to request specific columns.
- Each occurence of '-O' beyond the first would just insert the passed
keywords after those requested by the previous options, as if by '-o',
inconsistently with the behavior for the first occurence.
These behaviors had more annoying consequences:
- Where the columns of some '-O' occurence appear in the display used to
depend on the actual position of '-O' with respect to other options,
despite the natural expectation that they should go near a single PID
column considered as an anchor regardless of other options adding
columns.
- Columns specified with multiple '-O' options would not be grouped
together.
- It used to be impossible to specify custom headers but for the last
column for columns that are next to each other (i.e., specified by
a single '-O' occurence).
which are now all lifted.
With these changes, '-O' can still be used alone to amend the default
display, but can now be used also in conjunction with any specific
display, and in particular "canned" ones invoked by '-j', '-l', '-u' or
'-v'.
******
This part discusses other ps(1) implementations' behaviors and compares
them to the one established by this change.
NetBSD seems to be the only other BSD having refined the meaning of
ps(1)'s '-O' option. While the behavior there is similar to the new one
here on the surface, it differs on the following points:
1. If no options requesting a specific display are present before the
first '-O' option, the appearance of '-O' triggers the insertion of
the default display, regardless of whether such specific display
options appear *after* it.
2. If options requesting a specific display appear before the first '-O'
and none specify a PID column, columns listed in the first '-O' are
appended to them (as '-o' would do), but columns passed by further
'-O' options are then inserted next to the columns of the first '-O'
options.
Behavior of point 1 seems to have only one advantage: To allow to
customize the default display by first using '-O' and then other options
appending to it, but as the default display finishes with the COMMAND
column, it is unlikely that one wants to use '-o' or other specific
display options after '-O' (NetBSD's ps(1) does not suppress duplicate
columns). A much simpler and easy-to-understand way to reach that
effect in FreeBSD, if it really proves useful, would be to introduce
a new explicit option that inserts the default display.
The column-appending behavior of the first '-O' option in point 2 can be
also achieved by using '-o' instead. As '-O' is used to insert columns
after the PID one, which is located near the left in the default and all
"canned" displays, we found it more consistent and practical to push its
columns completely to the left on the absence of a PID column. The
effect of multiple '-O' options in NetBSD when no PID column has been
requested beforehand is also cumbersome and inconsistent with the
documentation (it is likely a bug).
Both NetBSD-specific behaviors exposed above also have the disadvantage
that the position of '-O' options with respect to other ones is
meaningful in ways that are not obvious and that are arguably not
desirable as '-O' is meant to append columns after an anchor (the PID
column).
Linux's procps-ng's ps(1) is very limited in its handling of '-O', and
more generally when mixing options tweaking the display. '-O' causes
insertion of the default display (like NetBSD does). If '-o' options
are specified, '-O' must come before them. '-O' is not usable with
canned display options. Additionally, only one '-O' option may appear
on the command line, limiting header customization.
The only case in which these implementations and ours behave in the same
way with respect to '-O' is if only a single '-O' option and no other
options changing the display are specified.
MFC after: 3 days
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49615 (code)
Differential Revision: https://reviews.freebsd.org/D49616 (manual page)
(cherry picked from commit 5dad61d9b949bb859450266c6accebc106f50fcc)
Now that removal of non-explicitly-requested duplicate columns work with
a O(n) algorithm, remove the ad-hoc optimization of crushing the canned
displays' formats after first use and constify their format strings.
No functional change intended.
This change could also be useful if/when allowing, e.g., to double
letters of canned displays to indicate their columns should not be
subject to automatic removal of duplicates (e.g., 'ps -ll').
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49614
(cherry picked from commit fd6b81712eb9a77bbe484954d18fe1fc4a27116b)
Before this change, when stacking up more columns in the display through
command-line options, if user requested to add some "canned" display
(through options '-j', '-l', '-u' or '-v'), columns in it that were
"duplicates" of already requested ones (meaning that they share the same
keyword, regardless of whether their headers have been customized) were
in the end omitted.
However, this mechanism did not work the other way around, i.e.,
requesting some canned display(s) first and then adding some columns
that are duplicates (through '-o' or '-O') would not remove them from
the canned display. Additionally, it did not take into account keyword
aliases (which also lead to displaying the same information).
This whole mechanism of removing columns from requested canned displays
when there are duplicates is useful in a number of scenarios:
1. When one wants the columns of a canned display, but with some of them
in a different order and at the edges of the bulk. This needs the
change here to move columns after the bulk (previously, only moving
them before the bulk would work).
2. To combine multiple canned displays to get more information without
repeating common columns. This part has been working before and
this behavior is unchanged.
3. In combination with requesting a canned display and additional
columns after it, ensure that a single COMMAND column appears at the
end of the display (to benefit from the fact that a last COMMAND
column can extend further to the right).
Point 2 above implies that, when multiple canned displays are requested,
we should keep the leftmost column with same keyword. However, columns
requested explicitly by '-o' have priority (as the natural extension of
point 1's behavior before this change), and in this case all matching
columns in canned displays must be suppressed.
To this end, when adding requested options to the display's list, we
stop trying to find an earlier matching column (which is incidentally
a O(n²) algorithm). Instead, we do a first pass over all requested
options once they have all been added to the display's list (in
scan_vars()). For each keyword, we note if it was requested at least
once explicitly (through '-o' or '-O'), in addition to setting
'needuser' and 'needcomm' (as before). Then, a second pass decides
whether to keep each column. A column is removed if it should not be
kept absolutely (i.e., it wasn't specified via '-o' or '-O') and there
is either a matching column that must be kept (determined during the
first pass), or we have seen one already (earlier canned displays take
precedence).
Matching columns are in fact not only those that have same keywords, but
also those that have keywords determined to be aliases to each other.
Some previous commits ensured that this determination is O(1) and in
practice just a few assembly instructions.
find_varentry() has been kept although its last caller has been removed
as next commit will reintroduce a call to it.
MFC after: 3 days
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49612
Differential Revision: https://reviews.freebsd.org/D49613 (manual page)
(cherry picked from commit cd768a840644ad55029ce9c3d41fc52b5045e0cc)
With this change, an alias keyword is resolved once and for all by
merging specifications of the keyword (or chain of keywords) it points
to. This merge in particular determines the final attributes of the
alias keyword, as well as the final keyword it points to, which uniquely
determines which information is printed (all non-alias keywords are
assumed to display different data).
Also, the alias resolving code has been moved into the resolve_alias()
function and helpers (e.g., merge_alias()). Aliases are still resolved
lazily as needed by default. The new top-level resolve_aliases()
function is used to resolve them at once at program startup if ps(1) has
been compiled with PS_CHECK_KEYWORDS defined. Else, it can also be
called directly from a debugger.
This is in preparation for removing columns that actually display the
same information in a subsequent commit, as this requires being able to
(quickly) determine if they are aliases to each other.
***
The merge process is now explicit and more flexible. Previously, all
fields of the resolved keyword were unconditionally used for the alias
(the pointer to an alias keyword structure was replaced by one to the
aliased keyword's one). Now, field 'final_kw' on the alias keyword will
store a pointer to the aliased keyword structure (and not only its name,
as a subsequent commit will need the structure address). Fields
'header', 'field' and 'flag' are taken from the aliased keyword if they
have default values (NULL or 0), else the alias' values prevail. This
allows an alias to override one or more of these fields. All fields
after 'oproc', because they describe the information to display
consistently with each other, are always taken from the aliased keyword.
merge_alias() checks that the values of these fields in the alias
keyword structure are unspecified (NULL, or some neutral value like
0 and UNSPEC).
While here, parsefmt() was reworked to avoid any direct recursion and
the break-up/recombination steps that were used when processing aliases.
The latter was due to the mutual recursion with findvar() and its
odd-for-that-purpose signature. findvar() has been removed in the
process. Simplification of parsefmt() also allows to be more precise
with the errors reported (in particular, the case of an empty keyword
with a specific header would just be reported as a "keyword not found"
message).
While here, introduce the check_keywords() function, performing sanity
checks on the declared keywords, currently only validating that they are
declared in alphabetical order. As for resolve_aliases(), this function
is called at startup on PS_CHECK_KEYWORDS, else it is available to be
called from a debugger.
Ideally, alias resolution should be done at compile time. In practice,
it seems doing so at runtime was never a problem (there are only a few
aliases compared to all available keywords, and there's currently at
most one level of aliasing). With the changes here, it seems very
unlikely to become one even if many more keywords, aliases or aliasing
levels are added.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 193e68d5174ffde70acc427f9d830797df9a13cb)
This is in preparation for a change in how aliases are resolved, itself
in preparation for being able to quickly identify columns displaying the
same information (same final keyword).
Add the new UNSPEC ("unspecified") type, as the keywords' type field is
only used by the kvar() and rvar() output routines, and has no meaning
for alias keywords. In particular, this will allow to check that no
specific type is associated to any alias. An immediate benefit is that
now most keywords have UNSPEC as their "type", which now makes
kvar()/rvar() explicitly fail (instead of trying to print a character,
as the previous CHAR type was requesting). A developer introducing new
keywords via copy-paste will thus be reminded that it also needs to set
'type' meaningfully if using kvar()/rvar() as the output routine.
Rename field 'alias' of keywords ('VAR' type) into 'aliased'. Move it
just after the keyword's name, as it makes it easier to spot aliases in
the list. Make it a union, as a subsequent commit will... alias it with
a pointer to another 'VAR' structure. Turn aliases' header string (""
for all aliases) into NULL. It is currently not used, but will be when
introducing the new "merge" procedure for aliases (where it will mean:
Use the header of the aliased keyword).
While here, rename vars[] into the more descriptive keywords[].
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 090f0e5820efc7f9459d1e4eb1be17fb98848df5)
Building on the previous commit that moved the 'width' field from VAR
(structure representing the meaning of a keyword) to VARENT (structure
representing an actual column in a display), it is now possible to
declare the field 'var' of VARENT as a constant reference.
At this point, it could be possible to constify the var[] array
containing all the recognized keywords. However, we do not do it as
a subsequent commit will change the way alias keywords are resolved,
causing their fields to be modified to reflect the final values to use
after alias resolution.
In parsefmt(), forget about allocating a new VAR for the selected
keyword to be pointed by the corresponding column (VARENT), and instead
just keep a pointer to that structure in var[].
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49611
(cherry picked from commit 1dbb1cca9b8b7874f22c06f5340686361c76da47)
Some column's width depends not only on the information displayed but
also on the its header, which may have been customized. Consequently,
that width is a property of the actual column and should not be attached
to the keyword specifying which information to print.
This change fixes a bug where multiple columns displaying the same
information (same keyword) but with different headers would have the
same width, although they should not if they have long enough headers
that have different lengths (the width computed from the largest header
would be applied to all the corresponding keyword's columns).
Remove sizevars(), as the 'width' field is now initialized directly in
parsefmt(), which creates the VARENT structures.
While here, remove var[]'s sentinel line, and consequently adjust the
upper limit in showkey()'s loop and findvar()'s binary search.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49610
(cherry picked from commit 490f251bf90dbfda8043e2d1f4a71dd3a91a8628)
The only information that find_varentry() needs and uses is
a keyword/var name. The rest of the fields in the passed VAR are
unused.
Changing its signature will ease introducing new calls to
find_varentry() in subsequent commits, as there no VAR object will exist
to be passed but just a name.
Reviewed by: kib
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49609
(cherry picked from commit c1e5a7fdad631458768fc45a82b4d43bade8d0c8)
This is in preparation for changing the behavior of the '-O' option.
While here, reformat the definition of 'struct varent', fix formatting
of that of 'struct var' and expand slightly their herald comments.
More reformatting/commenting in 'ps.h'.
No functional change intended.
Reviewed by: kib
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49607
(cherry picked from commit 07a7557addc03acd28aaae55b90419c4ef9d9ad1)
Now that it is officially documented in the manual page.
Reviewed by: kib
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49606
(cherry picked from commit 8a3e58ed618109e7af16c54affb1d5f98e5feb27)
No functional change (intended).
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 0d320eb5edc37f6c1bfa5eabc0309350b87c08ad)
The preamble has been revamped to give a thorough overview of the
different aspects of the ps(1) command in the following separate
paragraphs:
1. What it outputs.
2. Which processes are listed.
3. Which information is displayed by process.
4. How lines are sorted.
5. Considerations about the (mostly broken) output width.
6. Backwards compatibility features.
Fix or expand the description of several options and some keywords to
match their actual behavior.
Expand the STANDARDS section, noting the options conforming to POSIX and
those that do not (but may be changed to), as well as current diverging
behaviors.
Expand the BUGS section with a thorough description of other known
problems.
While here, document the POSIX-specified '-A' option. We have been
supporting it since 2004 (commit "Support more POSIX/SUSv3 options:",
a4c8a745a8, r127499) and it has been standard for longer. It
seems now highly unlikely we will ever want to use it for any other
purpose, so just stop trying to hide it.
While here, re-order flags according to mdoc(7)'s prescription. Given
the current state, this also requires less changes than, e.g., putting
all uppercase flags first.
While here, move the detailed specifications of keywords from the
DESCRIPTION to the KEYWORDS section.
While here, fix the formatting of some references to keywords.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49605
(cherry picked from commit ddf144a04b53d8599bdd00747e1b6d77e695c292)
On MFC, the original description for '-f' was kept, as swapping out has
not been removed from stable/14, and was slightly tweaked to be clearer.
Reviewed by: des
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D41422
(cherry picked from commit e17a2944a6e08478b9c073ba62c46f6714af16a2)
I just noticed a slight issue with the '-D' option. Basically,
I accidentally typed something along the lines of:
ps -Dboth-p303
I.E. missing out the "space". Instead of giving an error, it behaved as
if I'd just typed "ps".
Looking at bin/ps/ps.c, where the -D option is parsed, it doesn't
error-out if there is no valid match.
This commit fixes the bug.
(cherry picked from commit 3f0b80bc1537c257f3bd68592832ec8cb65e1c58)
The -p option does not imply -x, it is merely a different mode that ps
uses. Remove that statement from the -p option, effectively rolling back
d6ae056e9dc96c2db45982ac358ba9ed716a9202.
pstef@ introduced the -D option in 5c0a1c15ff
which also turns ps into a similar mode. List the -D option along with
the others in the first sentence of the second paragraph of the
DESCRIPTION section for completeness and correctness sake.
Pointed out by: pstef@
Differential Revision: https://reviews.freebsd.org/D42552
(cherry picked from commit ba44650a0b1e3b0f52554380937a3ffc16d396f3)
This flag is used in field 'cr_flags', which is never directly visible
outside the kernel. That field is however exported through 'struct
kinfo_proc' objects (field 'ki_cr_flags'), either from the kernel via
sysctls or from libkvm, and is supposed to contain exported flags
prefixed with KI_CRF_ (currently, KI_CRF_CAPABILITY_MODE and
KI_CRF_GRP_OVERFLOW, this second one being a purely userland one
signaling overflow of 'ki_groups').
Make sure that KI_CRF_CAPABILITY_MODE is the flag actually exported and
tested by userland programs, and hide the internal CRED_FLAG_CAPMODE.
As both flags are currently defined to the same value, this doesn't
change the KBI, but of course does change the KPI. A code search via
GitHub and Google fortunately doesn't reveal any outside uses for
CRED_FLAG_CAPMODE.
While here, move assignment of 'ki_uid' to a more logical place in
kvm_proclist(), and definition of XU_NGROUPS as well in 'sys/ucred.h'
(no functional/interface changes intended).
Reviewed by: mhorne
Approved by: markj (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46909
(cherry picked from commit 09290c3a0c82524138973b14f393379edf733753)
A ports exp-run (PR 283410) showed one port to be affected
(sysutils/procs), which has been fixed upstream and in the ports tree.
All additional indirect references to CRED_FLAG_CAPMODE we found after
the code search mentioned in the original commit message are
automatically generated from our headers by FFI mechanisms, so
automatically disappear at recompilation (and the KBI is not changed, as
explained above, so recompilation is not needed).
It takes a non-optional parameter string, one of "up", "down", or "both"
that can request tree traversal in the chosen directions. This adds PIDs
from the paths to the selection of PIDs and can be used together with -d
to draw a subset of the process tree.
Differential Revision: https://reviews.freebsd.org/D41231
This reverts commit ca8c0d5e81.
By commiting ca8c0d5e81 I was hoping that the existing option -d
could just be extended to work with -p to implement a feature that was
and I think is still needed, that is to show all descendant processes
of a given process id or a set of process ids.
After a complaint from -current which may represent a wider
dissatisfaction with this change in the program's behavior, I think it
will be better to revert ca8c0d5e81 and reintroduce this feature
using a separate option -D.
This prevents ps from being built with address sanitizer instrumentation.
Reviewed By: trasz
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31048
When -H is specified, for kernel threads the command is formatted as
"<proc name>/<td name>" and truncated to MAXCOMLEN. But each of the
proc name and td name may be up to MAXCOMLEN bytes in length.
Also handle the ki_moretdname field to ensure that the full thread name
gets printed. This is already handled correctly when formatting for
"-o tdname".
Reported by: freqlabs
Reviewed by: freqlabs
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25840
realtime priorities
The current `ps -axO rtprio' show threads running at interrupt
priority such as the [intr] thread as '1:48' and threads running
at kernel priority such as [pagedaemon] as normal:4294967260.
This change shows [intr] as intr:48 and [pagedaemon] as kernel:4.
Reviewed by: kib
MFC after: 1 week (together with -r362369)
Differential Revision: https://reviews.freebsd.org/D25660
This flag will now show the processor number on which a process is running.
This change was inspired by PR129965. Initially I didn't think that the
patch attached to it was correct -- it sacrificed ki_estcpu use in "cpu"
for ki_lastcpu and I thought that the old functionality should be kept and
the new (cpu#) one added to it. But I've since discovered that ki_estcpu is
sched_4bsd-specific. What's worse, it represents the same thing as
ki_pctcpu, except ki_pctcpu is universal -- so "%cpu" has been using it
successfully. Therefore, I've decided to replace information based on
ki_estcpu with information based on ki_oncpu/ki_lastcpu.
Key parts of the code and manual changes were borrowed from top(1).
PR: 129965
Reported by: Nikola Knežević
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25377
Fix the rtprio option that for some reason was progessively becoming an
option showing the priority class of threads. In particular:
- use the constants defined in sys/sys/rtprio.h instead of those defined in
sys/sys/priority.h: this helps making clearer that the code actually is
about realtime priorities and not standard scheduler priorities;
- remove the PRI_ITHD case that has nothing to do with realtime priorities;
- convert the priority levels to realtime priority levels using the same
formulas used for pri_to_rtp function in sys/kern/kern_resource.c.
- remove outdated note "101 = not a realtime process" in the man page and
replace it with a more useful reference to man 1 rtprio.
Approved by: src (mckusick), manpages (bcr), gerald (mentor)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D25266
Use %hs (locale-based encoding) instead of %s (UTF-8) format for
strings that are expected to be in current locale encoding (date/time,
process names/argument list).
PR: 241491
Reviewed by: phil
Differential Revision: https://reviews.freebsd.org/D22160
