0

I'm trying to find a efficient way to programmatically monitor, from user mode, what processes are started on my computer (OS X Yosemite). Since NSWorkspaceDidLaunchApplicationNotification only works for apps and kqueues (NOTE_EXIT) only allows one to monitor a specific process, dtrace probes seemed to be the way to go. I've played around with both /usr/bin/execsnoop and /usr/bin/newproc.d (and stripped down versions, that just install a single probe (syscall::posix_spawn:return) and do nothing else (e.g. no prints)).

These do great job getting me the info I need, but when I start an app that kicks off multiple processes/quickly execs multiple commands (e.g. VMWare Fusion) - the probe(s) seem to noticeably impact the system. Specifically kernel_task consistently spikes to 50%+ CPU usage for a few seconds and the OS UI (mouse, etc) noticeable slows/lags...if the dtrace probes are not installed, this behavior is never observed.

So a few questions:
1) any way to avoid this perf issue? (dtrace #pragmas?)
2) are dtrace probes cumulative? (if I install dtrace probes do I need to manually uninstall them, or does ctl+C clear/disable them?)
3) any way to see what dtrace probes are currently installed?

I'm not attached to using dtrace - but am not aware of another (non-polling) way to get the pid/process name of things that are started on OS X :/

patrick
  • 380
  • 2
  • 14

1 Answers1

2

  1. I am extremely surprised to see a measurable impact after enabling a single probe; does even

    dtrace -n syscall::posix_spawn:return

    cause a problem? If so, are you running short of memory? DTrace does require a (by default) modest amount and its initialisation may be pushing you over the edge. Do you see the problem with anything besides Fusion? It appears to suffer from performance problems of its own on Yosemite.

  2. Probes are shared between consumers. If there is only one running consumer (e.g. dtrace) then all DTrace probes will be removed when it exits. If two consumers have enabled the same probe then it will remain active until the last consumer exits.

  3. Maybe. Someone with access to the OS X source code could modify this script.

Robert Harris
  • 1,522
  • 9
  • 11
  • tx for your response! 1. yes, totally agree. Ran just your snippet and saw same behavior (`kernel_task` spike/ very laggy UI) anytime a large number of processes/shell commands were executed (Fusion execs about 50 during startup!). A python script that exec'd `ls` and `ps` in a loop got same behavior - again **only** but consistently, when dtrac'ing. I'm decent on memory - 16GB? 2. makes sense. 3. Cool, will take a look. Ok, so here's the interesting part, the dtrace probe: `dtrace -n syscall::exe*:return` reduces `kernel_task` spike & there's no more UI lag! Odd... – patrick Jan 08 '15 at 03:44