Почему iosnoop (Io snooping files на диске) возвращает пути с вопросительными знаками?

Question

Если я бегу

sudo iosnoop | grep "gem" 

, а затем в другом терминале перспективе

gem env 

в iosnoop терминале я вижу:

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 
    ... 

Какие вопросительные знаки рядом рубин в путь к файлам обрабатываются:

ruby ??/1.8/rubygems.rb 

? И как я могу найти абсолютный путь для всех этих файлов?

Дополнительный вопрос - почему ошибки здесь:

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

Короткие ответы:

1. The ?? означает, что остальной путь неизвестен,
2. вы не можете извлечь абсолютный пути и
3. это функция, а не ошибка, из DTrace на OS X.

Объяснение этих пунктов требует некоторое знакомство с DTrace; , если это необходимо, тогда начните с introduction to the Solaris version.

iosnoop - это сценарий, который использует видимость DTrace . В частности, он использует io провайдера start и done зонды; пусковой зонд предоставляет запрос bufinfo_t, целевого устройства devinfo_t и соответствующий файл fileinfo_t. fileinfo_t не является родным типом Дарвина: - это структура, предоставляемая dtrace (1), которая обеспечивает удобную абстракцию файла в интересах пользователей. Например, среди его членов есть fi_pathname, который должен указывать полный путь к файлу.

Наличие абстрактного описания защищает пользователей и их скрипты , начиная с знания и изменения в базовой операционной системе . Теоретически он также позволяет использовать один скрипт для работы в разных операционных системах .

Файл info_t сконструирован и заполнен динамически с использованием DTrace translator, описанного в /usr/lib/dtrace/io.d. Это показывает преобразование из конкретных типов ОС в абстракцию. В случае Snow Leopard я вижу, что fi_pathname построен из строки «?? /», за которой следуют некоторые производные буфера ввода-вывода.Я не эксперт Дарвина, но Я полагаю, что он просто не записывает полные пути в своих vnodes. Это, следовательно, является источником "??" в выводе вашего сценария, а также причина, по которой я предполагаю, что абсолютные пути недоступны.

И, наконец, ошибки DTrace. По каким-то причинам порт DTrace от Apple 3 тонко составляет crippled тем, что он исключает трассировку различных процессов, и сообщение об ошибке, которое вы видите, является характерным симптомом. В частности, жалоба о линии

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

и получается, что (опять же, на Snow Leopard), пытаясь оценить uid на любом из launchd, diskimages-help и kernel_task процессов приводят в точности этой ошибки , Я полагаю, что эти процессы являются «вне границ», а ошибки, которые вы видите, - это последствия модификаций Apple.

Answer 2

Хотя ответ выше, дает хорошую техническую подготовку, если вы просто хотите, чтобы получить полный путь к файлу открытых файлов я могу сделать это с помощью сырого DTrace на OS X с помощью:

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

Это будет show file открывается, но не читает и не записывает. Я получил от этого удобного DTrace одной страницы лайнеров Брендана Грегга: http://www.brendangregg.com/DTrace/dtrace_oneliners.txt

К сожалению, я до сих пор не понимаю, почему iosnoop не дает полный пути, когда кажется, что теоретически это возможно.