Find out everything about any process on your box.
Use ktrace to trace kernel activity for any process.Every major new version of the operating system has a learning curve. There’s just no way around it. Services advance, hopefully, and support files need to be changed accordingly.
The problem is that with the operating system changing so fast it sometimes takes a while for the documentation to catch up. This leaves you, the admin, holding the bag when adjusting your configurations with little help from the outside world.
Have no fear, ktrace is here.
Ktrace allows you to trace events going through the kernel. Using this incredibly powerful utility you can get an easy look into what’s going on in the recesses of your system.
Let me use a real example to illustrate how incredibly useful ktrace is.
Installations that care about security tend to dislike guest access to file servers regardless of what form it takes. This is easy enough to do on a server, but how do you do this with OS X client?
It was fairly well known that on 10.2 all of this information was kept inside NetInfo. With a little bit of digging you would find an entry under the config directory for the AppleFileServer that would allow you to turn off any form of guest access. Bye-bye drop boxes, hello security!
So, you added this bit flip into your standard client image and felt pretty smug about yourself. Problem is when 10.3 came around this all went out the window and you were back to square one. Sure it may be common knowledge now where the configuration is, but walk with me here a bit.
You take stock of the situation. You know the file server is the AppleFileServer process and that hasn’t changed. You’ve scoured NetInfo and found nothing of use. You know that there is most likely a flat file on the system that is used for this, but where? You could grep your entire harddrive, but geez, that’s not very elegant is it?
Instead with ktrace and two minutes of time you’ll have your answer.
Ktrace will launch a process while telling the kernel to keep track of what the process does. Ktrace takes this information and saves it to a dump file. You then can use kdump to turn that dump file into plain English where knowledge will ensue.
First make sure that the AppleFileServer process is not running. Can’t have two servers running at the same time now, can you?
Next use ktrace to launch the server.
sudo ktrace AppleFileServer
Give it a minute or too to log some good information then kill off the server and use ktrace to turn off all kernel traces so you don’t waste your processor.
sudo killall AppleFileServer sudo ktrace -C
If you now look in the directory that you were in when you ran the commands you should see a ktrace.out file. This is the raw dump of the kernel information. Not readable by humans. You’ll need to use the kdump command to convert this to a readable form. For extra credit you’ll use this with the ‘open’ command to pull it up in TextEdit
sudo kdump -f ktrace.out > AppleFileServerTrace.txt; open AppleFileServerTrace.txt
TextEdit should now be open with a file many pages in length. A quick scan of it should immediately show you what you are looking for. However, we’ll be a bit more methodical about it. Do a search on ‘open’ and you’ll find all of the files that the process wanted to open. Some didn’t exist and some did. You could also guess that Apple would put the configuration into a property list file, like every other config file they have. So you could search on “plist” too. Either way after a tiny bit of digging you should see this:
845 AppleFileServer CALL open(0xbffff1f0,0,0x1b6) 845 AppleFileServer NAMI "/Library/Preferences/com.apple.AppleFileServer.plist"
A quick trip to the Finder will show you that the file exists and can be opened, like any plist file, by a text editor or the Property List Editor application.
But wait, the fun doesn’t stop there! Not only does ktrace show you the file that was accessed it also logs what was read into the file. Here you’ll find the fleck of gold you’re searching for.
All you need to do to block guest access is to switch “true” to “false” in the /Library/Preferences/com.apple.AppleFileServer.plist and your problem is solved with plenty of time left for a long lunch.
Ktrace might not be a full blown Swiss Army knife, but it’s at least one of the little ones that you can use as a keychain. It has a tendency to be a bit verbose, but that’s a good thing for you. Plus it’s got some very cool options.
For example, I was trying to get a feel for what DirectoryService was doing on a server that was slowing down without reason. You can try killing off DirectoryService and then launching it with ktrace, but by the time you get there the kernel has already restarted it since it is one of the new Mach_init processes that get launched on demand.
I was about to get annoyed until I read the man page for ktrace. In addition to using it to launch a process you can have it attach to an already existing process and trace either the current children of that process or any new process that the parent process will spawn.
A quick peek at the beautiful looking Activity Monitor showed that the parent process of DirectoryService was mach_init, which makes a whole lot of sense. So instead of launching DirectoryService with ktrace, I instead attached ktrace to the mach_init process. It has the id of 2 and I told ktrace to monitor any newly spawned children of the parent process. Then I killed off DirectoryService and waited for it to restart.
sudo ktrace -p 2 -i sudo killall DirectoryService
Give it a moment to reappear in the process list then turn off the logging and convert it to text.
sudo ktrace -C sudo kdump -f ktrace.out > DSTrace.txt; open DSTrace.txt
Everything you need to know about what DirectoryService was doing is in the txt file.
Sure this isn’t something that you are going to be using every day. But when the time comes, ktrace is the bomb!