dtrace discuss - Nov 2007 - Running DTrace early in OSX boot process

At WWDC, some Apple folks discussed turning on DTrace early
in the boot process.  I gather that this uses anonymous
tracing, but I''m not at all sure where they started up the
DTrace program.  Any suggestions on how to do this?

FWIW, my notion is to have DTrace log a variety of "major
events" (e.g., exec, fork, open), feeding the output to a
logging script.  So, I need the system to be in a state that
can support file I/O, scripting, etc.

-r
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development

Rich Morin wrote On 11/10/07 21:28,:
>At WWDC, some Apple folks discussed turning on DTrace early
>in the boot process.  I gather that this uses anonymous
>tracing, but I''m not at all sure where they started up the
>DTrace program.  Any suggestions on how to do this?
>  
>
Refer to the ''Anonymous Tracing'' chapter of DTrace guide.
>FWIW, my notion is to have DTrace log a variety of "major
>events" (e.g., exec, fork, open),
>
Any tracing that you do at prompt can be done even here.
>feeding the output to a
>logging script.
>
The data is stored in kernel and can be retrieved later on
[after the system booted up] using ''dtrace -ae''.
-surya
>  So, I need the system to be in a state that
>can support file I/O, scripting, etc.
>
>-r
>  
>

On Sat, Nov 10, 2007 at 08:58:12AM -0700, Rich Morin
wrote:
> At WWDC, some Apple folks discussed turning on DTrace early
> in the boot process.  I gather that this uses anonymous
> tracing, but I''m not at all sure where they started up the
> DTrace program.  Any suggestions on how to do this?
Something seems at least a bit off with regard to Apple''s
implementation of
anonymous tracing:

# dtrace -A -n BEGIN
dtrace: failed in CFURLCreateDataAndPropertiesFromResource with code -10:
Unknown error: 0

Adam

-- 
Adam Leventhal, FishWorks                        http://blogs.sun.com/ahl

On Nov 11, 2007, at 9:43 PM, Adam Leventhal wrote:
> On Sat, Nov 10, 2007 at 08:58:12AM -0700, Rich Morin wrote:
>> At WWDC, some Apple folks discussed turning on DTrace early
>> in the boot process.  I gather that this uses anonymous
>> tracing, but I''m not at all sure where they started up the
>> DTrace program.  Any suggestions on how to do this?
>
> Something seems at least a bit off with regard to Apple''s  
> implementation of
> anonymous tracing:
>
> # dtrace -A -n BEGIN
> dtrace: failed in CFURLCreateDataAndPropertiesFromResource with code  
> -10: Unknown error: 0
	D''OH! You guys are great at finding problems :-).

	I filed: <rdar://problem/5595357> Enable dtrace anonymous tracing

	James M

Although anonymous tracing looks quite nifty, I''m not sure that
I really need to start tracing things _that_ early, at least at
this point.  My notion, really, was to trace pid 1 (or somesuch)
and all of its descendants, logging a few key systemn calls.  Is
there a way to do this without using anonymous tracing?

-r
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development

On Nov 11, 2007, at 9:43 PM, Adam Leventhal wrote:
> Something seems at least a bit off with regard to Apple''s  
> implementation of
> anonymous tracing:

Now that the Leopard DTrace userland source is posted I can elaborate  
on the Mac OS X implementation of anonymous tracing:

First, build and install the following extension (it''s called  
dtrace_dof.kext and it keeps the compiled form of your dtrace script  
on its Info.plist.) --

$  cd dtrace_dof_kext
$  xcodebuild
$ sudo ditto build/Release/dtrace_dof.kext/ /System/Library/Extensions/ 
dtrace_dof.kext
Now compile your script using the "-A" flag to direct the compiled  
bytecodes to the dtrace_dof.kext --


$ sudo dtrace -A -n ''BEGIN { stack(12); }''
dtrace: saved anonymous enabling in /System/Library/Extensions/ 
dtrace_dof.kext/Contents/Info.plist
dtrace: do ''sudo touch /System/Library/Extensions/'' and reboot
to
enable changes
Arrange to rebuild Extensions.mkext and friends at next boot --

$ sudo touch /System/Library/Extensions/
Reboot --

$ sudo shutdown -r now
<REBOOTS>

When the machine comes back to life, claim the "anonymous" tracing by
running dtrace with the "-a" flag. --

$ sudo dtrace -a
dtrace: buffer size lowered to 2m
CPU     ID                    FUNCTION:NAME
   0      1                           :BEGIN
               mach`dtrace_probe+0xa74
               mach`dtrace_probe+0x1e08
               mach`dtrace_init+0x7cc
               mach`bsd_autoconf+0x3c
               mach`bsd_init+0x638
               mach`kernel_bootstrap+0x150
               mach`Call_continuation+0x14
               0xdeadbeef
^C
Clean out dtrace_dof.kext --

$  sudo dtrace -A
dtrace: removed anonymous enabling in /System/Library/Extensions/ 
dtrace_dof.kext/Contents/Info.plist
dtrace: do ''sudo touch /System/Library/Extensions/'' and reboot
to
enable changes

$ sudo touch /System/Library/Extensions/

$ sudo shutdown -r now
<REBOOTS>

You only need to build and install the dtrace_dof.kext once.


SCP
--
Steve Peters
scp at mac.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20071219/dce83c99/attachment.html>

At 10:25 AM -0800 12/19/07, Steve Peters wrote:
> Now that the Leopard DTrace userland source is posted I can
> elaborate on the Mac OS X implementation of anonymous
> tracing:...
Although anonymous tracing looks like just the ticket for some
projects, it is not appropriate to my needs, for two reasons:

  *  If the dtrace(1) command can''t be run yet, it''s likely
that
     the perl(1) command can''t, either.  So, I wouldn''t be
able
     to start up the script that accepts and archives the output.

  *  It seems rather presumptuous to take over a system resource
     that can only have one customer.

Instead, I''d like to know how to set up my Perl script to run as
early as possible in Leopard, Solaris, etc.  If anyone can give
me specific hints on this, I''ll look into putting up wiki pages.

-r
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development

At 14:21 -0800 22/12/07, Rich Morin wrote:
>Instead, I''d like to know how to set up my Perl script to run as
>early as possible in Leopard, Solaris, etc.
On Mac OS X 10.5 there really isn''t a good solution to this.  pid 1 
is launchd, and launchd starts everything asynchronously (relying on 
''demand pull'' to sort out the ordering).  Thus,
there''s no easy place
to hook the system so that your script is definitely running before 
other specific subsystems ("/etc/rc" is no more).

In terms of supported solutions, the best you can do is create a 
launchd daemon and have launchd start it for you.  There are a couple 
of issues with this:

o What you''ll see in the trace will change from boot-to-boot, based 
on process scheduling variances.  That''s less than ideal.

o You probably won''t trace anything early because perl requires a lot 
of the system to be up and running.  For example, it''s very likely 
that perl calls something like <x-man-page://3/getpwnam>, and will do 
a demand pull of DirectoryServices.

In terms of unsupported solutions, you can either go rummaging around 
in the kernel or in launchd/launchctl.  Check out 
system_specific_bootstrap in:

<http://www.opensource.apple.com/darwinsource/10.5/launchd-257/launchd/src/launchctl.c>

S+E
-- 
Quinn "The Eskimo!"                   
<http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware