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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
