|Priority:||4 - Normal|
|Created by:||Joshua M. Clulow [X]|
|Reported by:||Joshua M. Clulow [X]|
|Assigned to:||John Levon [X]|
Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2019-09-13T10:39:09.010Z)
2019-09-26 Bubble Boy (Release Date: 2019-09-26)
Once the kernel will agree to read
argv from the address space of another process, and expose it via
/proc/$pid/argv (see OS-3463), we should enhance
ps to use this new facility to show additional arguments.
If the user invokes
ps with the SVR4
-f flag, we will attempt to display the full argument string on the end of each output line. If the user specifies
-o args, we will still (by default) constrain to 80 columns. If the user uses the BSD
-w, we will constrain the output width to 132 columns. If they use
-ww, we will not constrain the width.
It occurred to me, long ago while looking at this, that we might want to do more than one thing here; e.g., we might want to preserve a longer (though not infinitely long) set of packed argument strings in the kernel so that we can see what the process was started with. The proc file
argv is subject to modification by the process itself (as is
pargs output today), which is sometimes but probably not always what people want when they use
I'd presumed there was some reason this never got done, so thanks for responding.
As you point out, both pargs and "pfexec ps.1b" already behave like this. We wouldn't be proposing removing the ways to see pr_psargs.
Furthermore, setproctitle() and friends exist precisely so the user can see the new text in things like ps(1). It seems a little wilful to ignore that.
So I'm not saying we shouldn't preserve the original list too (and add a pargs option to dump it), but it seems orthogonal to this particular issue IMHO.
Having played with this change a little:
239 case 'w': /* increase display width */ 240 if (twidth < 132) 241 twidth = 132; 242 else /* second w option */ 243 twidth = NCARGS; 244 break;
This looks like a bug dating from when terminals couldn't possibly have a width > 132. Seems like I should fix that
We need to modify both version of ps as well as pgrep (pargs already has a separate mechanism we don't touch here).
pgrep -d, postgres
pgrep -ld, postgres
pgrep -fl postgres, check output is modified args where necessary
pgrep -x with/without -f
pgrep -f is stripping trailing blanks
pgrep output of non-control chars, junk etc. (argv-junk.c)
pgrep with very long argv
pgrep with SHORT_PSARGS set
pkill as above
process with > 4096 argv0 string as well as total longer, shorter argv, verify output
ps output of non-control chargs (argv-junk.c)
ps -ef output with changed argv
ps -e output
ps with SHORT_PSARGS
ps aux, auxw, auxww behave as expected with large and small terminals
ps -o pid,comm,fname,args
pargs -e, not -e sanity check
test of cmdline file, ps, top, etc. in an lx zone
cat /proc/*/cmdline - including zsched, sched, etc.
OS-7931 ::refstr would be useful
OS-7932 ::ps -s could show service FMRIs
OS-7934 ptree could show service FMRIs
OS-3513 ptools should see more process arguments
Reviewed by: Jerry Jelinek <email@example.com>
Reviewed by: Jason King <firstname.lastname@example.org>
Approved by: Jerry Jelinek <email@example.com>