I am running a D script on a heavily loaded system and it dies with dtrace: processing aborted: Abort due to systemic unresponsiveness I do have destructive actions enabled with #pragma D option destructive (I tried running with -w as well) and it doesn''t help. Is there any way tu turn off deadman timer explicitly? - akolb
Hi, Sorry about not getting back to you sooner on this.>I am running a D script on a heavily loaded system and it dies with >dtrace: processing aborted: Abort due to systemic unresponsiveness > >I do have destructive actions enabled with #pragma D option destructive (I >tried running with -w as well) and it doesn''t help. Is there any way tu turn >off deadman timer explicitly? > >This is strange. What version of Solaris are you on and what architecture? Are you running as root in the global zone? If not root, what privs does your user have assigned? Outside of enabling destructive actions you can''t explictly disable the deadman timer. Assuming that there isn''t any outside issues affecting us (incorrect timers etc) you could try and increase the 3 variables that control deadman function. They are mentioned in the DTrace tips and tricks presentation found at: http://learningsolaris.com/docs/dtrace_tips_public.pdf As you will see they are ''dtrace_deadman_user'', ''dtrace_deadman_interval'' and ''dtrace_deadman_timeout''. Try bumping them all up significantly and seeing if that makes any difference. If you still have the problem and no-one else has suggestions, I''ll happily look at the system if you give me details. Jon.
Hi * Jon Haslam <Jonathan.Haslam at Sun.COM> [2007-05-18 18:30 +0100]:>> I am running a D script on a heavily loaded system and it dies with >> dtrace: processing aborted: Abort due to systemic unresponsiveness >> >> I do have destructive actions enabled with #pragma D option destructive (I >> tried running with -w as well) and it doesn''t help. Is there any way tu >> turn off deadman timer explicitly? >> > > This is strange. What version of Solaris are you on and what architecture? > Are you running as root in the global zone? If not root, what privs does > your user have assigned?I''m not the OP, but I have seen similar problems in a VM (both Parallels and VMWare fusion running on a MacBook Pro 2.16GHz Core 2 Duo. I figured there were hi res timer problems arising from the VM implementation, but -w did not solve the problem. Incidentally, truss seems to hang the VM completely in Parallels (not VMWare) in nevada b63, and VMWare fusion is in beta, so I''m not clear if there''s a lot of mileage in solving for these platforms... maybe there are be some Parallels bugs to be filed though if we could get to the root cause. cheers, J -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 447 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070518/51f0288a/attachment.bin>
> Hi, > > Sorry about not getting back to you sooner on this. > > >I am running a D script on a heavily loaded system and it dies with > >dtrace: processing aborted: Abort due to systemic unresponsiveness > > > >I do have destructive actions enabled with #pragma D option destructive (I > >tried running with -w as well) and it doesn''t help. Is there any way tu turn > >off deadman timer explicitly? > > > > > > This is strange. What version of Solaris are you on and what architecture? > Are you running as root in the global zone? If not root, what privs does > your user have assigned?This is amd64 system running bits around build 60. I am running as a normal user in a global zone and have dtrace_proc,dtrace_user,dtrace_kernel. Everything works normally, except the deadman timer firing with destructive actions enabled.> Outside of enabling destructive actions you can''t explictly disable the > deadman timer. Assuming that there isn''t any outside issues affecting > us (incorrect timers etc) you could try and increase the 3 variables that > control deadman function. They are mentioned in the DTrace tips and tricks > presentation found at: > > http://learningsolaris.com/docs/dtrace_tips_public.pdf > > As you will see they are ''dtrace_deadman_user'', ''dtrace_deadman_interval'' > and ''dtrace_deadman_timeout''.I have to change these with MDB, they do not have corresponding DTrace options, right? - akolb
> This is amd64 system running bits around build 60. I am running as a normal > user in a global zone and have dtrace_proc,dtrace_user,dtrace_kernel. > Everything works normally, except the deadman timer firing with destructive > actions enabled.OK. Is this a heavily loaded system?>> Outside of enabling destructive actions you can''t explictly disable the >> deadman timer. Assuming that there isn''t any outside issues affecting >> us (incorrect timers etc) you could try and increase the 3 variables that >> control deadman function. They are mentioned in the DTrace tips and tricks >> presentation found at: >> >> http://learningsolaris.com/docs/dtrace_tips_public.pdf >> >> As you will see they are ''dtrace_deadman_user'', ''dtrace_deadman_interval'' >> and ''dtrace_deadman_timeout''. > > I have to change these with MDB, they do not have corresponding DTrace > options, right?Yes - change them with mdb(1). My reply on Friday was a little terse really, sorry. If you''re going to try and tune the deadman out then your best bet would be to just bump ''dtrace_deadman_timeout'' up. Its default value is 10000000000 (in nanoseconds). For those that are interested, I''ve put up a blog entry on the deadman mechanism which you can find at: http://blogs.sun.com/jonh/date/20070521 Jon.
Alexander Kolbasov''s email at 5/18/2007 6:44 PM, said:>> This is strange. What version of Solaris are you on and what architecture? >> Are you running as root in the global zone? If not root, what privs does >> your user have assigned? > > This is amd64 system running bits around build 60. I am running as a normal > user in a global zone and have dtrace_proc,dtrace_user,dtrace_kernel. > Everything works normally, except the deadman timer firing with destructive > actions enabled. >A normal user with privileges cannot avoid the deadman even with destructive actions enabled. You must be root (i.e. have all privileges) in order to do this (by design). If you have the ability to run mdb(1) on the kernel, then you probably have root; correct? Try running your invocation as root. Thanks, Jarod
>> This is amd64 system running bits around build 60. I am running as a >> normal >> user in a global zone and have dtrace_proc,dtrace_user,dtrace_kernel. >> Everything works normally, except the deadman timer firing with >> destructive >> actions enabled.Aarggh. I completely blew past you''re statement about being a non root user with privs. D''oh! A case of less haste, more speed... Jon.>> > > A normal user with privileges cannot avoid the deadman even with > destructive actions enabled. You must be root (i.e. have all > privileges) in order to do this (by design). > > If you have the ability to run mdb(1) on the kernel, then you probably > have root; correct? Try running your invocation as root. > > Thanks, > > Jarod > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org