A few comments to what has already been posted:
pfiles
It is true that you can find the same information as what lsof is producing by
using a script that uses the Solaris 'pfiles' command. One such example is
"PCP" (http://www.unix.ms/pcp/). I have to warn against this. [i]pfiles will
stop the
Pfiles should be rewritten to not stop processes. I had to go look at
the code to make sure you were right on this. If lsof can gather open
file info without stopping processes, why can't pfiles do that.
Or, if there is some additional reliability/consistency to be gained by
stopping the process
Chip Bennett writes:
> Pfiles should be rewritten to not stop processes. I had to go look at
> the code to make sure you were right on this. If lsof can gather open
> file info without stopping processes, why can't pfiles do that.
lsof does it because it reads the volatile kernel structures on t
Hi all,
A user with dtrace_proc and dtrace_user privileges can see the
profile:::tick-1 probe:
$ ppriv $$
28999: -bash
flags =
E: basic,dtrace_proc,dtrace_user,proc_owner
I: basic,dtrace_proc,dtrace_user,proc_owner
P: basic,dtrace_proc,dtrace_user,proc_owner
L: a
Hi Toby,
> However when I run D code using this probe I don't see any output
> unless I add the dtrace_kernel privilege.
>
> Here the D code I am using (this is in a script that I run as dtrace
> -s tick-1.d):
>
> /*
> * Count off and report the number of seconds elapsed
> */
> dtrace:::BEGIN
On Fri, Dec 12, 2008 at 09:45:08AM -0500, James Carlson wrote:
> Chip Bennett writes:
> > Pfiles should be rewritten to not stop processes. I had to go look at
> > the code to make sure you were right on this. If lsof can gather open
> > file info without stopping processes, why can't pfiles do t
Nicolas Williams writes:
> But the point is that kmdb scripting and lsof are on the same footing.
Yes, it's exactly the same thing by slightly different means.
The difference, and it's not much, is that a user of mdb looking at
the kernel likely knows that unless the target is stopped (as with md
On Fri, Dec 12, 2008 at 10:28:09AM -0600, Nicolas Williams wrote:
> I have a very out of date script lying around that did just that.
I found it, but all it does is walk the proc table. Still, it's way
faster than pfiles and almost[*] as good as pfiles. It seems to work on
OpenSolaris 2008.11.
COW snap-shots for kernel memory. :-)
Chip
> -Original Message-
> From: dtrace-discuss-boun...@opensolaris.org [mailto:dtrace-discuss-
> boun...@opensolaris.org] On Behalf Of James Carlson
> Sent: Friday, December 12, 2008 11:00 AM
> To: Nicolas Williams
> Cc: dtrace-discuss@opensola
On Fri, Dec 12, 2008 at 11:59:43AM -0500, James Carlson wrote:
> Nicolas Williams writes:
> > But the point is that kmdb scripting and lsof are on the same footing.
>
> Yes, it's exactly the same thing by slightly different means.
>
> The difference, and it's not much, is that a user of mdb looki
Happy Friday,
I'm having a hard time wrapping my head around the proper way to use
conditional expressions in DTrace.
The following line seems to not want to compile:
args[0]->b_flags & B_READ ? (
@dev_r[args[1]->dev_statname,args[1]->dev_pathname]=sum(args[0]->b_bcount)
) : ( @dev_w[args[1]->de
On Fri, Dec 12, 2008 at 12:05:21PM -0800, Brett Monroe wrote:
> Happy Friday,
>
> I'm having a hard time wrapping my head around the proper way to use
> conditional expressions in DTrace.
>
> The following line seems to not want to compile:
>
> args[0]->b_flags & B_READ ? (
> @dev_r[args[1]->dev
BTW, in case I wasn't clear, I agree that we need interfaces for listing
open resources that use locking to produce correct output. I don't
think stopping processes to produce that output is a good idea though.
Nico
--
___
dtrace-discuss mailing list
d
Ahh, wonderful. Thanks Jonathan!
--Brett
On Fri, Dec 12, 2008 at 12:51 PM, Jonathan Adams wrote:
> On Fri, Dec 12, 2008 at 12:05:21PM -0800, Brett Monroe wrote:
>> Happy Friday,
>>
>> I'm having a hard time wrapping my head around the proper way to use
>> conditional expressions in DTrace.
>>
>
Lars Bruun-Hansen wrote:
> pfiles
> It is true that you can find the same information as what lsof is
> producing by using a script that uses the Solaris 'pfiles' command.
> One such example is "PCP" (http://www.unix.ms/pcp/). I have to warn
> against this. [i]pfiles will stop the process while it
Nicolas Williams wrote:
> On Fri, Dec 12, 2008 at 09:45:08AM -0500, James Carlson wrote:
>
>> Chip Bennett writes:
>>
>>> Pfiles should be rewritten to not stop processes. I had to go look at
>>> the code to make sure you were right on this. If lsof can gather open
>>> file info without s
David Powell wrote:
> Lars Bruun-Hansen wrote:
>
>> pfiles
>> It is true that you can find the same information as what lsof is
>> producing by using a script that uses the Solaris 'pfiles' command.
>> One such example is "PCP" (http://www.unix.ms/pcp/). I have to warn
>> against this. [i]pfiles
On Fri, Dec 12, 2008 at 02:00:25PM -0800, Dan Mick wrote:
> For the record: 'kmdb' and 'mdb -k' are different beasts. kmdb == mdb
> -K == "boot with -k" ==
> "console only" == "stop the kernel in its tracks". mdb -k is "have a
> gander at the still-running kernel".
I knew I'd get in trouble o
> >
> >It would be really useful if you could elaborate on how pfiles
> >screwed up your daemons. Though pfiles will stop a process to get
> >its information, it does so for a very short period of time and in a
> >fashion that should be undetectable to the target process. Unless a
19 matches
Mail list logo
