Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Monitor system calls UNIX
As a transplant from other *nix operating systems, I'm used to system call monitoring tools like truss (on Solaris) and strace (on Linux).

While I haven't found anything quite like these for Darwin, sc_usage comes close. It provides a running statistical breakdown of system calls for any process ID (pid) specified on the command line. Although I haven't yet figured out how to parse its output, I expect it'll aid in figuring out where a particular app is getting hung up. In conjunction with fs_usage (mentioned in a previous hint by Ben Hines), you can also track down what files are being called. Note that this must be run in a Terminal window as root (generally via 'sudo').

Usage is:
sudo sc_usage [pid]
Apple has a developer note describing the tool, with some examples, and you can always type man sc_usage in Terminal for typically laconic Unix documentation.

(Thanks go to Fred S., Apple's Open Source Engineering Lead, who posted about these utilities in a MacPerl thread.)

[Sudo Editor's caution: f you're not comfortable with the terminal and root privileges, I would recommend holding off on this hint. ]
  • Currently 2.25 / 5
  You rated: 4 / 5 (4 votes cast)

Monitor system calls | 7 comments | Create New Account
Click here to return to the 'Monitor system calls' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Please stop being patronizing
Authored by: babbage on Mar 05, '02 12:01:36PM
What's with the marked increase in "if you're afraid of the terminal, this could be a bad idea" editorial footnotes recently? This comment looks pretty non-descructive and safe -- all it does it let you observe what a running process is doing at a "turn & cough" level with the kernel. You might not be able to do much with this as a newbie, but it's certainly interesting information, and you can learn more about how your system works by watching it. Please don't scare people away like this.

And then the comment after this, where we are editorially advised to obey whatever an installer tells us to do. Well, that's not such sound advice either. As commenters over on MacSlash have been saying today, the reflex to force a reboot after all installations is not at all necessary unless you're upgrading the kernel itself. There really isn't any good reason to force you to close out other running programs and reboot for each install -- the modern protected memory system OSX provides makes all of this irrelevant now. Until software developers figure out that almost none of them need to do this -- except for Apple, and anyone else you might allow to muck around with the kernel -- then yes, you can generally ignore these reboot orders.

Sorry to rant at the sudo editor like this, you're doing a good job running the site and I appreciate the hard work. But the recent patronizing tone, with both editors, is getting really annoying -- like having a content-free "first post!" pasted in from Slashdot with each article over here. Please try to refrain from these editorial footnotes unless you really have something to add.

[ Reply to This | # ]

Authored by: Anonymous on Mar 05, '02 02:48:31PM

I think 'ktrace' is the BSD equivalent of truss and strace.

Unfortunately, it seems the MacOSX kernel doesn't have support compiled in...

[ Reply to This | # ]
Authored by: Bishop on Mar 05, '02 07:06:30PM

I believe that too, but I'm not sure, since ktrace does not work I'd be interested to here any info anyone might have on strace/ktrace for MacOS X since it is a very useful tool in GNU-Linux.

[ Reply to This | # ]
Authored by: hysterion on Mar 07, '02 08:57:33PM
OS X has /usr/bin/ktrace, but (according to this bug report) still misses kdump to display its output.

[ Reply to This | # ]
Some other tools
Authored by: axolotl on Mar 05, '02 11:05:55PM

Other tools that are available are the command line program "sample" (man sample) and the application in the /Developer/Applications folder. These perform statistical sampling of a running process's call tree and produce a report. Not as handy as a true tracing capability, but provides another way of looking at a process while it's running.

- Merle

[ Reply to This | # ]
even better...
Authored by: soy_bomb on Mar 05, '02 11:32:48PM
I deal with rooted UNIX/UNIX-like boxen all the time at my work in data centers for clients. If you really want to see what is going on with your UNIX system, try using:
Its UNIX command for listing open files. Doesn't even require su/sudo/system admin access. Generally the "root kits" I find on rooted machines go after this command first. For good reasons. lsof gives a bounty of information of what a UNIX/UNIX-like OS is doing. Open files, sockets, processes and the sort. Masking your "root kit" means modifying lsof along with ps, top, ls, du, netstat, and few other low level platform specific utils. In my work, I carry around a 3.5" loaded with lsof for about 10 different UNIX/UNIX-like platforms -- thank god for universal FAT32 support in UNIX.
Don't be afraid of This is a read-only UNIX command. To learn more open and type:
man lsof
Then search Google for more tips and tricks with lsof.

[ Reply to This | # ]
Fred S.
Authored by: pudge on Mar 06, '02 03:19:11PM

He is no longer working for Apple, FWIW. I believe the comment on the MacPerl list that you're referring to was from Sept. 2000. :)

[ Reply to This | # ]