Date: Wed, 21 Jan 2009 11:38:31 +0200 From: Danny Braniss <danny@cs.huji.ac.il> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: ps acting weird? Message-ID: <E1LPZXb-000N4U-V6@kabab.cs.huji.ac.il> In-Reply-To: <alpine.BSF.2.00.0901201544450.74507@fledge.watson.org> References: <E1LPGw2-0008Ja-OX@kabab.cs.huji.ac.il> <alpine.BSF.2.00.0901201544450.74507@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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 > thanks Robert, it is always educational to read your answers! i have set kern.ps_arg_cache_limit, as you suggested to 4k, but i think 512 would have been enough (excluding those pathological cases of 'command *') btw, this tomcat/java command line was 312 (why not use a config file!). which brings on another issue: ps -o command= -p 777 /usr/local/diablo-jdk1.6.0/bin/java -Djava.endorsed.dirs= -classpath [...] while ps -o comm= -p 777 java thanks, danny
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1LPZXb-000N4U-V6>