Warum gibt iosnoop (IO Snooping-Dateien auf der Festplatte) Pfade mit Fragezeichen zurück?

Question

Wenn ich

sudo iosnoop | grep "gem" 

und dann in einem anderen Terminal läuft

gem env 

im iosnoop Terminal laufe ich sehe:

dtrace: error on enabled probe ID 4 (ID 1106: io:mach_kernel:buf_strategy:start): illegal operation in action #3 at DIF offset 0 
dtrace: error on enabled probe ID 4 (ID 1106: io:mach_kernel:buf_strategy:start): illegal operation in action #3 at DIF offset 0 
dtrace: error on enabled probe ID 4 (ID 1106: io:mach_kernel:buf_strategy:start): illegal operation in action #3 at DIF offset 0 
dtrace: error on enabled probe ID 4 (ID 1106: io:mach_kernel:buf_strategy:start): illegal operation in action #3 at DIF offset 0 
dtrace: error on enabled probe ID 4 (ID 1106: io:mach_kernel:buf_strategy:start): illegal operation in action #3 at DIF offset 0 
... 
dtrace: error on enabled probe ID 4 (ID 1106: io:mach_kernel:buf_strategy:start): illegal operation in action #3 at DIF offset 0 
    501 54406 R 21523616 512  bash ??/bin/gem 
    501 94092 R 141320288 4096  bash ??/bin/gem 
    501 94092 R 141320168 4096  ruby ??/1.8/rubygems.rb 
    501 94092 R 141320208 4096  ruby ??/1.8/rubygems.rb 
    501 94092 R 141319208 4096  ruby ??/rubygems/errors.rb 
    501 94092 R 141319856 4096  ruby ??/rubygems/specification.rb 
    501 94092 R 141319864 4096  ruby ??/rubygems/specification.rb 
    501 94092 R 141319872 4096  ruby ??/rubygems/specification.rb 
    501 94092 R 141319888 4096  ruby ??/rubygems/specification.rb 
    501 94092 R 141319896 4096  ruby ??/rubygems/specification.rb 
    501 94092 R 141319904 4096  ruby ??/rubygems/specification.rb 
    501 94092 R 141319928 4096  ruby ??/rubygems/specification.rb 
    501 94092 R 141319936 4096  ruby ??/rubygems/specification.rb 
    501 94092 R 141319944 4096  ruby ??/rubygems/specification.rb 
    501 94092 R 141320176 4096  ruby ??/1.8/rubygems.rb 
    501 94092 R 141320184 4096  ruby ??/1.8/rubygems.rb 
    ... 

Was die Fragezeichen in der Nähe von Rubin in dem ist Pfad zu den Dateien werden behandelt:

ruby ??/1.8/rubygems.rb 

? Und wie kann ich den absoluten Pfad zu all diesen Dateien finden?

Zusätzliche Frage - warum sind die Fehler hier:

dtrace: error on enabled probe ID 4 (ID 1106: io:mach_kernel:buf_strategy:start): illegal operation in action #3 at DIF offset 0 

?

Answer 1

Die kurzen Antworten sind:

1. Die ?? bedeuten, dass der verbleibende Pfad nicht bekannt ist,
2. Sie nicht den absoluten Pfad und
extrahieren kann
3. dies ist ein Feature, kein Bug, von DTrace auf OS X.

Eine Erklärung dieser Punkte benötigt etwas Vertrautheit mit DTrace; falls dann mit der introduction to the Solaris version starten.

iosnoop ist ein Skript, das das DTrace-Beobachtbarkeits-Framework ausnutzt. Insbesondere verwendet es die io Anbieter start und done Sonden; Die Startsonde gibt die bufinfo_t, Anforderung eines Zielgeräts devinfo_t und die entsprechende Datei fileinfo_t frei. Die fileinfo_t ist kein nativer Darwin-Typ: Es ist eine Struktur, die von dtrace (1) zur Verfügung gestellt wird, die eine bequeme Abstraktion einer Datei zum Vorteil der Benutzer bietet. Zum Beispiel ist unter seinen Mitgliedern fi_pathname, die den vollständigen Pfadnamen einer Datei geben sollte.

Mit einer abstrahierten Beschreibung schirmt Benutzer und ihre Skripte von der Kenntnis und Änderungen der zugrunde liegenden Implementierung des Betriebssystems ab. In der Theorie ermöglicht es auch ein einzelnes Skript, das auf verschiedenen Betriebssystemen insgesamt ausgeführt wird.

Ein fileinfo_t wird dynamisch erstellt und dynamisch mit einem DTrace translator beschrieben in /usr/lib/dtrace/io.d. Dies zeigt die Transformation von den OS-spezifischen Typen zur Abstraktion. Im Fall von Snow Leopard sehe ich, dass fi_pathname aus der Zeichenfolge "?? /" gebildet wird, gefolgt von einige Derivate des IO-Puffer.Ich bin kein Darwin Experte aber Ich folge, dass es einfach nicht vollständige Pfadnamen in seinem vnodes aufzeichnet. Dies ist also der Ursprung des "??" in der Ausgabe Ihres Skripts und auch der Grund, warum ich davon ausgehe, dass die absoluten Pfadnamen nicht verfügbar sind.

Schließlich Ihre DTrace Fehler. Aus welchen Gründen auch immer, Apples Port von DTrace ist subtil crippled in dem es verhindert, dass von verschiedenen Prozessen verfolgt, und die Fehlermeldung, die Sie sehen, ist ein charakteristisches Symptom. Insbesondere ist die Beschwerde über die Linie

start_uid[this->dev, this->blk] = (int)uid; 

und es stellt sich heraus, dass (wieder auf Snow Leopard), versucht uid auf eines der Ergebnisse launchd, diskimages-help und kernel_task Prozesse in genau diesen Fehler zu bewerten . Ich nehme an, dass diese Prozesse sind "außerhalb der Grenzen" und die Fehler, die Sie sehen, sind die Folgen der Änderungen von Apple.

Answer 2

Während die Antwort über einen guten technischen Hintergrund gibt, wenn Sie nur den vollständigen Pfad der geöffneten Dateien erhalten möchte ich bin in der Lage über diese mit rohen DTrace auf OS X zu tun:

sudo dtrace -n 'syscall::open*:entry { printf("%s %s",execname,copyinstr(arg0)); }' 

Dieser Wille Zeige Datei öffnet, aber nicht liest oder schreibt. Ich habe diese von Brendan Greggs praktisch DTrace Einzeiler Seite: http://www.brendangregg.com/DTrace/dtrace_oneliners.txt

Leider habe ich immer noch nicht verstehen, warum iosnoop nicht den vollständigen Pfad zu geben, wenn es scheint, dass es theoretisch möglich ist.