OS-3513: ptools should see more process arguments

Details

Issue Type:Bug
Priority:4 - Normal
Status:Resolved
Created at:2014-10-31T22:43:02.000Z
Updated at:2019-09-13T10:39:09.896Z

People

Created by:Joshua M. Clulow [X]
Reported by:Joshua M. Clulow [X]
Assigned to:John Levon [X]

Resolution

Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2019-09-13T10:39:09.010Z)

Fix Versions

2019-09-26 Bubble Boy (Release Date: 2019-09-26)

Related Issues

Related Links

Description

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 ps flag -w, we will constrain the output width to 132 columns. If they use -ww, we will not constrain the width.

Comments

Comment by Joshua M. Clulow [X]
Created at 2019-08-08T04:06:23.601Z

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 ps.


Comment by John Levon [X]
Created at 2019-08-08T09:22:21.678Z

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:

due to:

 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
too?


Comment by John Levon [X]
Created at 2019-09-11T10:44:47.397Z

See https://github.com/illumos/ipd/blob/master/ipd/0010/README.md

We need to modify both version of ps as well as pgrep (pargs already has a separate mechanism we don't touch here).


Comment by John Levon [X]
Created at 2019-09-12T16:45:50.439Z

Testing:

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[0], 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.


Comment by Jira Bot
Created at 2019-09-13T10:39:09.896Z

illumos-joyent commit c6dd2307128aa25ac346f7818440cd5cfd1f7221 (branch master, by John Levon)

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 <jerry.jelinek@joyent.com>
Reviewed by: Jason King <jason.king@joyent.com>
Approved by: Jerry Jelinek <jerry.jelinek@joyent.com>