Re: [dtrace-discuss] dtrace wired issue
On Jan 15, 2008 2:45 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Aubrey, ---snip-- setrlimit(RLIMIT_NOFILE, 0xFD7FFFDFEE80)= 0 openat(AT_FDCWD, /dev/dtrace/provider, O_RDONLY|O_NDELAY|O_LARGEFILE) = 3 fcntl(3, F_SETFD, 0x0001) = 0 fstat(3, 0xFD7FFFDFE8E0)= 0 getdents(3, 0xFD7FFF174000, 8192) (sleeping...) ---here, dtrace sleep almost 4 minutes ...and continue... How long does an ls -l /dev/dtrace/provider take? Yes, it costs almost 4 minutes. I doubt you are swapping with 2G of memory. You can run vmstat -S 2 to see if there is any swapping. I'll look a bit more... # vmstat -S 2 kthr memorypagedisk faults cpu r b w swap free si so pi po fr de sr cd -- -- -- in sy cs us sy id 0 0 0 1601116 1352560 0 0 717 2 53 0 2502 71 0 0 0 718 7222 2813 4 3 93 0 0 0 1516012 1236776 0 0 0 0 0 0 0 0 0 0 0 388 269 347 0 0 99 0 0 0 1516012 1236808 0 0 0 0 0 0 0 0 0 0 0 394 262 354 0 0 100 0 0 0 1516012 1236808 0 0 0 0 0 0 0 0 0 0 0 392 255 356 0 0 100 0 0 0 1516016 1236812 0 0 0 0 0 0 0 23 0 0 0 425 380 396 1 0 99 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 389 294 332 0 0 100 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 382 466 444 0 0 99 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 394 273 346 0 0 100 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 387 250 328 0 0 99 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 384 264 339 0 0 100 By the way, are you running on Indiana (just curious...). No, I'm using nevada. [EMAIL PROTECTED] /etc/release Solaris Express Community Edition snv_77 X86 Copyright 2007 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 06 November 2007 Thanks, -Aubrey ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] dtrace wired issue
Aubrey Li wrote: On Jan 15, 2008 2:45 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Aubrey, ---snip-- setrlimit(RLIMIT_NOFILE, 0xFD7FFFDFEE80)= 0 openat(AT_FDCWD, /dev/dtrace/provider, O_RDONLY|O_NDELAY|O_LARGEFILE) = 3 fcntl(3, F_SETFD, 0x0001) = 0 fstat(3, 0xFD7FFFDFE8E0)= 0 getdents(3, 0xFD7FFF174000, 8192) (sleeping...) ---here, dtrace sleep almost 4 minutes ...and continue... How long does an ls -l /dev/dtrace/provider take? Yes, it costs almost 4 minutes. So, what does ls -l /dev/dtrace/provider show? max I doubt you are swapping with 2G of memory. You can run vmstat -S 2 to see if there is any swapping. I'll look a bit more... # vmstat -S 2 kthr memorypagedisk faults cpu r b w swap free si so pi po fr de sr cd -- -- -- in sy cs us sy id 0 0 0 1601116 1352560 0 0 717 2 53 0 2502 71 0 0 0 718 7222 2813 4 3 93 0 0 0 1516012 1236776 0 0 0 0 0 0 0 0 0 0 0 388 269 347 0 0 99 0 0 0 1516012 1236808 0 0 0 0 0 0 0 0 0 0 0 394 262 354 0 0 100 0 0 0 1516012 1236808 0 0 0 0 0 0 0 0 0 0 0 392 255 356 0 0 100 0 0 0 1516016 1236812 0 0 0 0 0 0 0 23 0 0 0 425 380 396 1 0 99 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 389 294 332 0 0 100 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 382 466 444 0 0 99 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 394 273 346 0 0 100 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 387 250 328 0 0 99 0 0 0 1516016 1236812 0 0 0 0 0 0 0 0 0 0 0 384 264 339 0 0 100 By the way, are you running on Indiana (just curious...). No, I'm using nevada. [EMAIL PROTECTED] /etc/release Solaris Express Community Edition snv_77 X86 Copyright 2007 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 06 November 2007 Thanks, -Aubrey ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] dtrace wired issue
On Jan 15, 2008 4:43 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Aubrey Li wrote: On Jan 15, 2008 2:45 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Aubrey, ---snip-- setrlimit(RLIMIT_NOFILE, 0xFD7FFFDFEE80)= 0 openat(AT_FDCWD, /dev/dtrace/provider, O_RDONLY|O_NDELAY|O_LARGEFILE) = 3 fcntl(3, F_SETFD, 0x0001) = 0 fstat(3, 0xFD7FFFDFE8E0)= 0 getdents(3, 0xFD7FFF174000, 8192) (sleeping...) ---here, dtrace sleep almost 4 minutes ...and continue... How long does an ls -l /dev/dtrace/provider take? Yes, it costs almost 4 minutes. So, what does ls -l /dev/dtrace/provider show? max # ls -l /dev/dtrace/provider total 14 lrwxrwxrwx 1 root root 43 Sep 3 01:21 fasttrap - ../../../devices/pseudo/[EMAIL PROTECTED]:fasttrap lrwxrwxrwx 1 root root 33 Sep 3 01:21 fbt - ../../../devices/pseudo/[EMAIL PROTECTED]:fbt lrwxrwxrwx 1 root root 43 Sep 3 01:21 lockstat - ../../../devices/pseudo/[EMAIL PROTECTED]:lockstat lrwxrwxrwx 1 root root 49 Sep 3 01:21 lx_systrace - ../../../devices/pseudo/[EMAIL PROTECTED]:lx_systrace lrwxrwxrwx 1 root root 41 Sep 3 01:21 profile - ../../../devices/pseudo/[EMAIL PROTECTED]:profile lrwxrwxrwx 1 root root 33 Sep 3 01:21 sdt - ../../../devices/pseudo/[EMAIL PROTECTED]:sdt lrwxrwxrwx 1 root root 43 Sep 3 01:21 systrace - ../../../devices/pseudo/[EMAIL PROTECTED]:systrace err, now I got something interesting. It looks like this wired issue is caused by the ata driver bug which I reported on the opensolaris-bug mailing list. When I switch the system to the console mode(X is disabled), I got #dtrace -l snip scsi: WARNING: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],2/[EMAIL PROTECTED] (ata1): timeout: abort request, target=0 lun=0 scsi: WARNING: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],2/[EMAIL PROTECTED] (ata1): timeout: abort device, target=0 lun=0 scsi: WARNING: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],2/[EMAIL PROTECTED] (ata1): timeout: reset target, target=0 lun=0 scsi: WARNING: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],2/[EMAIL PROTECTED] (ata1): timeout: reset bus, target=0 lun=0 ID PROVIDERMODULE FUNCTION NAME 1 dtrace BEGIN 2 dtrace END 3 dtrace ERROR 4 lockstat genunix mutex_enter adaptive-acquire 5 lockstat genunix mutex_enter adaptive-block 6 lockstat genunix mutex_enter adaptive-spin 7 lockstat genunixmutex_exit adaptive-release 8 lockstat genunix mutex_destroy adaptive-release 9 lockstat genunixmutex_tryenter adaptive-acquire snip -Aubrey ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] destructive actions
Brian Kolaci wrote: Peter Shoults wrote: Brian Kolaci wrote: Chip Bennett wrote: Chip Bennett wrote: According to the manual, if you give all of the dtrace privs to a normal user, that user can access everything except destructive actions, which is still reserved for the super user. As such a user a ran a script that did a chip(10), and got the following error: dtrace: error on enabled probe ID 3 (ID 13: syscall::read:return): invalid kernel access in action #2 Pardon me, That should have been a chill(10). Sorry. Chip (not 10) ;-) Thanks alot. Its been a long time since I've read the manual. Should have known that... ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org Also, you would have to start the dtrace sccript with a -w option, if you do not, the destructive actions do not take. Actually, I think the script will not even run Yep, they knew that. But audit wants to make sure they can't even do it by mistake (for example, hidden in the first line of a D script). Well, it really wouldn't be hidden would it. It would have to be in the first line as an arg passed into dtrace. I guess I do not get it.all they would have to do is more the script and see if it has a -w on the first line.. ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
