DTrace

В DTrace есть довольно много очень полезных встроенных переменных.
Полный их список приведён здесь, а пока я расскажу лишь про несколько из них. В этой заметке мы рассмотрим простейшие переменные, а в последующих записях постепенно научимся использовать и более сложные.

Позволю себе разбить переменные на несколько групп. Помимо имени переменной, я также приведу её тип. Итак:

1) Имена файлов и каталогов
string cwd - имя текущего каталога того процесса, которому принадлежит текущий thread
string execname - символьное имя, которое было передано функции exec(2) для исполнения текущего процесса.

2) Процессы
id_t tid - номер текущего thread'а. Для thread'ов пользовательских процессов, это значение будет равно результату вызова pthread_self(3C).
pid_t pid - идентификатор процесса (PID) текущего процесса
pid_t ppid - parent PID текущего процесса
uid_t uid - пользовательский ID текущего процесса
gid_t gid - идентификатор группы (group ID) текущего процесса

3) Пробы
uint_t id - ID номер текущей пробы. Это тот самый номерок, что видно в таблице доступны проб при вызове команды dtrace -l
string probefunc - имя функции согласно описанию текущей пробы
string probemod - имя модуля согласно описанию текущей пробы
string probename - имя пробы согласно описанию текущей пробы
string probeprov - имя провайдера согласно описанию текущей пробы

4) Прочее
int errno - код ошибки, возвращённый последним системным вызовом, выполненным текущим thread'ом
uint64_t timestamp - текущее время счётчика наносекунд. Данный счётчик не привязан к текущему времени в системе, и потому должен использоваться только для относительных вычислений.

Использовать эти переменные можно как угодно - один из простейших вариантов применения приведён ниже. Я привожу полный текст скрипта, поэтому если вы его сохраните под именем script.d и сделаете этому файлу chmod u+x ./script.d, то его можно будет запускать прямо из командной строки. Пока не обращайте внимания на строку с pragma D option, про несколько полезных опций DTrace я расскажу через несколько дней.

ВНИМАНИЕ: в целях компактного размещения кода, я разбил длинные строки с printf на несколько строк. Если вы хотите запустить данный скрипт, вам следует склеить такие строки.



Запущенный на вашей машине, данный скрипт выдаст вам примерно следующее (будет ОЧЕНЬ много строк, так как мы ловим, согласно шаблону, все обращения к вызову write):

This guide has been around for quite some time, but I still wanted to write about it here.

Here is the link: Solaris Dynamic Tracing Guide

This guide has lots of very simple and useful examples, so it's a good starting point.

All these examples can be found in /usr/demo/dtrace, and if you open /usr/demo/dtrace/index.html in your browser, you'll see all the examples in a table, split by the guide chapters.

Одним из нововведений Solaris 10 являются привилегии - механизм, позволяющий легко ограничивать возможности пользователей или процессов в системе.

man privileges содержит список всех доступных привилегий, я же здесь пока затрону лишь те, которые относятся к DTrace.

Смысл всего этого вот в чём - DTrace это довольно опасное оружие в умелых руках, и потому простые пользователи Solaris не должны иметь к нему доступ так же, как и они не должны иметь доступа к файлам других пользователей. Поэтому, попытка выполнить команду типа dtrace -l из-под обычного пользователя приведёт к такой вот ошибке:

dtrace: failed to initialize dtrace: DTrace requires additional privileges

По умолчанию, только root может пользоваться DTrace. Чтобы позволить другим пользователям тоже как-то использовать DTrace, существуют три привилегии, которые им может выдавать администратор:

dtrace_proc - даёт пользователю лишь доступ к провайдеру pid. Естественно, доступна будет лишь информация о процессах, принадлежащих этому пользователю.
dtrace_user - даёт пользователю доступ к провайдерам profile и syscall, опять же в рамках процессов, принадлежащих этому пользователю.
dtrace_kernel - даёт доступ ко всем провайдерам, кроме pid, если он не позволен привилегией dtrace_proc. Губительные для ядра (kernel-destructive) функции недоступны.

Вот эти три функции считаются kernel-destructive:
breakpoint() - выбросит систему в отладчик ядра. На Sparc-системах вы окажетесь в ok приглашении OBP, а на x86 системах можете оказаться в kadb
panic() - вызовет панику ядра (смешно переводить слова, которые никогда по-русски не говорятся) в целях получения крэш-дампа
chill() - глобальный sleep, если хотите. Заставляет DTrace ждать указанное количество наносекунд. Естественно, это отразится на всей системе.

Так вот, обычному пользователю, какие бы вы ему привилегии не давали, доступа к этим трём функциям нет.

Вкратце, привилегии выдаются так:

Нужно добавить в файлик /etc/user_attr строку с указанием привилегий для конкретного пользователя. Скажем, если имя пользователя - greys, то вот эта строчка даст ему возможность творить с помощью DTrace всё, что только можно позволить с помощью привилегий простому пользователю:

greys::::defaultpriv=basic,dtrace_proc,dtrace_user,dtrace_kernel

ну, или если не хочется пользователю надолго давать такие привилегии, можно осчастливить лишь процесс его командной оболочки командой:

ppriv -s A+dtrace_user PID

В этом случае пользователь сможет провести необходимые ему эксперименты, но по выходу из оболочки он эти волшебные свойства утратит до следующего вашего приступа душевной доброты.

Процесс написания скрипта на языке DTrace - D - очень прост. После того, как вы выяснили, за чем вы хотели бы проследить в системе, нужно просто указать эти критерии в виде простейших фильтров проб, и подсказать, что делать DTrace, когда в процессе отладки попадается что-то удовлетворяющее критериям этих фильтров.

Начнём с простейшего: в DTrace есть две пробы, которые очень легко запомнить. В то же время, они бывают очень полезными при написании сложных d-скриптов. Называются эти пробы BEGIN и END, и исполняются они, как видно из названия, перед началом отладки и по её завершению.

Как видно из примера ниже, синтаксис у языка D прост, понятен и многим знаком по другим языкам программирования:



Если сохранить этот текст в файл, то позже его можно скормить команде dtrace в помощью ключика -s:

dtrace -s ./try.d

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


Первое поле - CPU - указывает процессор, на котором сработала та или иная проба DTrace. В данном случае мы пытались поймать встроенные пробы BEGIN и END, и потому они поймались на том же процессоре, который исполнял команду dtrace - 0.

Поле ID - это числовой код проб BEGIN и END, и если вернуться к предыдущей записи в блоге - Пробы в DTrace, то в таблице всех проб, доступных для использования, первыми стоят именно пробы BEGIN и END, под номерами 1 и 2.

Ну и последнее поле выводит имя той пробы, которая сработала. И если в теле процедуры обработки пробы есть какие-то операции, они будут выполнены. В нашем случае там стоят printf'ы, которые и выводят сообщения Hello, world и The End.

С такой же лёгкостью можно ловить какие угодно пробы! Например, следующий пример будет ловить всё новые случаи выполнения системного вызова write и указывать, какой процесс его запросил - pid и execname это встроенные переменные DTrace, я позже расскажу о них подробнее.

Итак, наш новый скрипт try.d, я для удобства не стал убирать из него BEGIN и END, чтобы была возможность сравнить и убедиться, что добавление любой другой пробы ничуть не сложнее. Как я уже говорил, можно отследить моменты входа и выхода из системного вызова - я в этом примере слежу за точками входа (entry):



Результатом будет бесконечная таблица, похожая на приведённую ниже. Вам следует нажать Ctrl+C чтобы прервать трассировку.



Видите, как просто и понятно получается отлаживать работающую систему? Сразу становится видно, что за эти несколько секунд, что я ждал, к системному вызову write прибегли: собственно dtrace (потому что вывод данных производил), rxvt (терминал), mozilla-bin (браузер, естессно) и icewm - мой оконный менеджер.

С таким же успехом можно вместо syscall::write:entry указать любую другую маску для проб DTrace.
Вот лишь несколько вариантов:

syscall::write:return - отслеживать лишь выходы из вызовов write
syscall::write: - отслеживать и входы, и выходы из вызовов write
syscall::: - отслеживать входы и выходы всех системных вызовов

Раз уж начал потихоньку рассказывать про DTrace, попробую самого простого не упускать тоже.

DTrace позволяет отлаживать любые процессы в Solaris 10, посредством проб. В ядро системы встроены модули, которые называются провайдеры - и каждый из них позволяет отлаживать какую-то область операционной системы.

Скажем, есть провайдер syscall, который позволяет отслеживать системные вызовы. Есть провайдеры sysinfo или vminfo, о функциональности которых можно догадаться из названия... И так далее.

Так вот, каждый провайдер предоставляет DTrace список проб - тех точек перехвата, где провайдер может отдать DTrace какую-то статистику. Скажем, для syscall пробами будут все системные вызовы, которые можно отслеживать с его помощью - read, write, wait, exec - вернее даже, те точки их выполнения, которые данный провайдер позволить отследить. Обычно это момент входа в системный вызов (entry) и возврата после его выполнения (return).

Чтобы просмотреть список всех провайдеров и всех проб, доступных DTrace, следует использовать такую команду:

dtrace -l



Весь список здесь приводить не стану - он просто огромен - у меня он занимает 36654 строки.

Есть ещё один очень полезный вариант команды, который позволяет найти конкретный системный вызов с целью выяснения, каким провайдером он предоставляется:

dtrace -l -f read



Из результата выполнения команды сразу же видно, что несколько провайдеров предоставляют возможность перехватывать их функции с именем read. Причём, если бы мы сделали dtrace -l | grep read, то было бы гораздо больше результатов, потому что есть очень много функций, в названии которых включается это слово.