Сегодня, перезагрузив ноутбук, я удивился странной дисковой активности – я не запускал ни одного ресурсоёмкого приложения, но показывал 1K+ обращений к диску.
“Непорядок” – решил я и привычно расчехлил dtrace:
$ sudo /usr/sbin/dtrace -n \
'syscall::open*:entry {printf("%s %s", execname, copyinstr(arg0));}'
Результатом было обилие строк вида:
1 19256 open_nocancel:entry find AppleLowshelf.nib 1 19256 open_nocancel:entry find AppleMultiband.nib 1 19256 open_nocancel:entry find AppleParametricEQ.nib 1 19256 open_nocancel:entry find DLSUI.nib 1 19256 open_nocancel:entry find Italian.lproj
find… Я не запускал его. Кто же?
$ ps ax | grep find | grep -v grep 265 ?? UN 0:36.76 find -s / ! ( -fstype hfs -or -fstype ufs ) -prune -or -path /private/tmp -prune -or -path /private/var/folders -prune -or -path /private/var/tmp -prune -or -path */Backups.backupdb -prune -or -print
Номер процесса у меня появился, но вот что дальше? Нужно найти родительский процесс, запустивший этот find…
Update. Спасибо opti и tsybulin за комментарии – поиск родительского процесса можно сделать в иерархическое представление в Activity Monitor или же командой “ps -Ao pid,ppid,command”. Но вот без dtrace не обойтись – в Activity Monitor может отразиться CPU, но не дисковая активность процесса.
К сожалению, я не смог вспомнить штатную утилиту Mac OS X, позволяющую строить дерево процессов, а время торопило – find мог закончиться до того, как я нашёл бы решение. Поэтому мне на помощь пришёл MacPorts, с помощью него я быстро поставил , делающая именно то, что мне было нужно, а именно строящая подробное дерево процессов с указанием подчинённости процессов.
$ port search pstree
pstree @2.33 (sysutils)
pstree shows the output of the ps command as a tree
$ sudo port install pstree
Записав дерево процессов в файл, я быстро определил, кто же запустил процесс find:
$ pstree > ps.txt $ view ps.tree |-+= 00216 root /bin/sh /usr/libexec/locate.updatedb | \-+- 00243 root su -fm nobody -c /usr/libexec/locate.updatedb | \-+= 00260 nobody /bin/sh /usr/libexec/locate.updatedb | |--- 00265 nobody find -s / ! ( -fstype hfs -or -fstype ufs ) -prune -or -path /private/tmp -prune -or -path /private/var/folders -prune -or -path /private/var/tmp -prune -or -path */Backups.backupdb -prune -or -print | \-+- 00266 nobody /bin/sh /usr/libexec/locate.mklocatedb -presort | \--- 00268 nobody locate.code /tmp/locatepPGiUebwvm/mklocates1B1ib6Fqw/_mklocatedb266.bigrams
Ложная тревога – виновником был , который обновляет базу данных для быстрого поиска файлов в shell. Например:
$ locate httpd-vhosts.conf /opt/local/apache2/conf/extra/httpd-vhosts.conf /private/etc/apache2/extra/httpd-vhosts.conf /private/etc/apache2/original/extra/httpd-vhosts.conf
“It is typically run once a week by the /System/Library/LaunchDaemons/com.apple.locate.plist job.” Неделя прошла, процесс при старте системы запустился.
Источник странной активности найден, снова впал у умиротворённое состояние. Надолго ли?



Довольно странная пляска с бубном — стандартный Activity Monitor тоже в состоянии показать дерево процессов. В нем же и без иерархического отображения можно добраться до родителя процесса через inspect. Его не достаточно?
Я подредактировал статью, спасибо. Излишни шаги по pstree, но вот dtrace был нужен, чтобы понять, кто же работает с диском.
ps -Ao pid,ppid,command
Спасибо, не использовал такую конструкцию. Но она самая простая – не нужны дополнительные утилиты.
Согласен, эти телодвижения излишни – про иерархический вид в Activity Monitor не знал, а ключи ps не использовал.
Спасибо :)
Самый простой способ посмотреть PID и PPID:
ps -ef
Плюс оно команду не обрезает по краю экрана…
Проверяю систему комментирования JS-Kit. Снова…
[...] This post was mentioned on Twitter by Ctrl-D, Ctrl-D. Ctrl-D said: #theapplegeek Поиск родительского процесса на примере одной странной ситуации http://theapplegeek.ru/archives/2190 [...]
Проверяю с iPod Touch, pls ignore
Цікава система, раніше не стикався, буду приглядатися. +1тест :)
Вот только под iPhone с WPTouch она слегка разлазится. Благо немного, буду писать разработчикам.
Тоже отличный вариант, спасибо.
Вопрос, чтобы эту жуткую строчку не запоминать как правильно её использовать в bash script?
$ sudo /usr/sbin/dtrace -n
‘syscall::open*:entry {printf(“%s %s”, execname, copyinstr(arg0));}’
Пробовал, жалуется на синтакс: “dtrace: invalid probe specifier syscall::open*:entry {printf(%s %s, execname, copyinstr(arg0));}: syntax error near “%”"
У тебя двойные кавычки исчезли при выполнении. Такое бывает, если команду в скрипте брать в другие кавычки.
Её нужно либо писать как есть, либо написать ещё один исполняемый скрипт вида:
cat ./Documents/Development/dtrace/01_files.d
#!/usr/sbin/dtrace -s
syscall::open*:entry
{
printf(“%s %s”, execname, copyinstr(arg0));
}