From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 09:38:33 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AD4E1065677 for ; Wed, 21 Jan 2009 09:38:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 122FD8FC1A for ; Wed, 21 Jan 2009 09:38:32 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LPZXb-000N4U-V6; Wed, 21 Jan 2009 11:38:31 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Robert Watson In-reply-to: References: Comments: In-reply-to Robert Watson message dated "Tue, 20 Jan 2009 15:49:09 +0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Jan 2009 11:38:31 +0200 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org Subject: Re: ps acting weird? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 09:38:33 -0000 > > 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