ps acting weird?

[Robert Watson]

On Tue, 20 Jan 2009, Danny Braniss wrote:

> I just stumbled on this, ps(1) gives different info if the user is root or a 
> simple mortal:
>
> simple-mortal> ps p8130
>  PID  TT  STAT      TIME COMMAND
> 8130  ??  Is     0:05.72 [java]
>
> root# ps p8130
>
>  PID  TT  STAT      TIME COMMAND
> 8130  ??  Is     0:05.73 /usr/local/diablo-jdk1.6.0/bin/java ...
>
> was this always like this?
> btw, this is on 7.1-stable

This happens when command lines are really long -- the kernel caches certain 
command line data when it's short (i.e., under a couple of hundred 
characters), but when it's long the only way to get it is to attach to the 
process's address space using debugging interfaces and read it from there. 
This requires ps(1) to have debugging rights for the target process, which 
will not always be true for simple mortal users, but will often be true for 
root.

You can set the kern.ps_arg_cache_limit sysctl to increase the limit, which 
will take effect when the command line is next changed (typically, when the 
program is run again, but there are some programs that update their command 
lines to show status information, in which case it will be when they next 
update).  This shows up particularly for Java command lines, which are often 
long.

I would be careful not to tune it up too high as it will use up kernel 
memory/address space, but setting it to, say, 4k or 8k on modern systems 
shouldn't really be a problem, especially since most commands don't have long 
command lines.  The problem this limit addresses is what happens when maxproc 
processes all set maximally-sized command lines.  I.e., if your maxproc is 
6,000, then fully filling the command line cache gives you 1.5MB of command 
line in kernel address space and memory - a lot, but very little compared to 
making the limit 4000 bytes, in which case it's more around 24MB.

Robert N M Watson
Computer Laboratory
University of Cambridge

>
> danny
>
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>