Volume Number: 24 (2008)
Issue Number: 01
Column Tag: MacEnterprise
By Philip Rinehart, Yale University
Following last month's article, let's look at some of the more interesting command line tools that have appeared. The first tool, pkgutil allows manipulation of the package database. Last month I also talked about the addition of dtrace. New to Leopard, major parts of the Dtrace ToolKit by Brendan Gregg have been added. Some of them can prove quite useful in diagnosing and troubleshooting particularly thorny problems.
pkgutil
A new command line utility has been added to Leopard, pkgutil. What does it do? From the man page, "pkgutil reads and manipulates the Installer's receipt database and flat packages." A database? That's new to Leopard. Let's look at where it is located. Change to /Library/Receipts/db. This database contains a record of all packages installed. Let's look at some of the basic options.
Forget. This option discards all the receipt data associated with an installed package. However, it only forgets the information, it does not touch the installed files. If you want to reinstall a package, this option is very useful, as the files will be overwritten and reinstalled. It won't be an upgrade; it will be a full reinstall.
Unlink. This option removes any files associated with a package. Be careful when using this option though, as it does no dependency checking and will not remove any directories that are contained within the package. However, if a package is only files, this command is quite useful.
Pkgs. All packages known on the system are listed. Here's why this option is important. Look at the Receipts directory, and then run the command pkgutil -pkgs. Take close look. Note that if the 10.5.1 update has been installed, there is no pkg receipt. It is only contained within the pkgutil database.
Repair. This option will run repair packages to repair the specified package identifier. Note however, that this option only repairs packages if they are known to the repair_packages utility found in /usr/libexec. Let's look at this a little more in depth.
repair_packages will repair packages with that are recorded in the standard package list. Here's how to check the list, open /usr/libexec, and run
repair_packages -list-standard-pkgs
Here's what is returned on my system:
System packages on '/': com.apple.pkg.BaseSystem com.apple.pkg.Essentials com.apple.pkg.BootCamp com.apple.pkg.BSD com.apple.pkg.iPodSupport com.apple.pkg.PodcastCapture com.apple.pkg.Directory com.apple.pkg.JavaToolsLeo com.apple.pkg.AdditionalEssentials com.apple.pkg.AdditionalSpeechVoices com.apple.pkg.AsianLanguagesSupport com.apple.pkg.MediaFiles com.apple.pkg.MigrationAssistant com.apple.pkg.Mail com.apple.pkg.AddressBook com.apple.pkg.iCal com.apple.pkg.Automator com.apple.pkg.DVDPlayer com.apple.pkg.iTunes com.apple.pkg.iChat com.apple.pkg.Java com.apple.pkg.Safari com.apple.pkg.OxfordDictionaries com.apple.pkg.X11User com.apple.pkg.ACL com.apple.pkg.VersionedDeveloperToolsSystemSupportLeo com.apple.pkg.DistributedBuildsSupportLeo com.apple.pkg.DeveloperToolsSystemSupportLeo com.apple.pkg.gcc4.0Leo com.apple.pkg.DeveloperToolsCLILeo com.apple.pkg.DevSDKLeo com.apple.pkg.X11SDKLeo com.apple.pkg.QuickTimeSDKLeo com.apple.pkg.OpenGLSDKLeo com.apple.pkg.WebKitSDKLeo com.apple.pkg.FireWireSDKLeo com.apple.pkg.BluetoothSDKLeo com.apple.pkg.CoreAudioSDKLeo com.apple.pkg.JavaSDKLeo com.apple.pkg.X11DocumentationLeo com.apple.pkg.ServerSetup com.apple.pkg.ServerAdminTools com.apple.pkg.update.os.10.5.1
Note all the packages, these are the only packages that are checked when verifying permissions. Packages can be added, but at this time, this command appears to only accept those that are known by the receipts database. One last thing, the repair_packages command allows individual verification of packages. Here's how:
/usr/libexec/repair_packages -verify -pkg com.apple.pkg.ServerSetup
Imagine using Apple Remote Desktop to verify or repair permissions on any number of packages! That about sums up the power of pkgutil and repair_permissions. I've not gone into all of the options, but there are a number of additional options to pkgutil whichpkgutil, which could be used. Read the man page and have fun!
Dtrace is quite powerful, but who has time to learn a new programming language? I don't,. that's for sure! Here's where some of the newly included programs can be explored and used when troubleshooting problems.
Snoop commands
Four "snooping" commands have been added, execsnoop, iosnoop, rwsnoop and opensnoop. I'll look at rwsnoop first. This command will observe reads and writes at the application level. It is really very verbose, and lists each and every read/write operation. It is also hooked in at the kernel level, so it is quite accurate. It's very simple to use to monitor a specific application. First, get the process id (PID), and then use the -p option. As an example, to monitor all Mail.app activity:
rwsnoop -p PID
This command monitors any read/write activity for the Mail.app application. Of course, one does not need to specify a particular application, but it is far more useful to only monitor one.
Input output monitoring
Three commands are included to track disk input/output, iotop, iopending, and iopattern. The one I like here is iotop. When troubleshooting a slow system, iotop presents a listing much like the unixUNIXnix top command. On a sluggish system, one could track the drive activity to determine what was slowing a system down.
Included scripts written in d
Lastly, many new commands have been included in Leopard, all written in d, the dtrace programming language. They are all located in /usr/bin. A couple of commands are particularly interesting. The first is creatbyproc.d. Run it in the following way:
dtrace -s creatbyproc.d
Note the output. It tracks files as they are created by process id. Let's look at another useful d script, filebyproc.d. This command will track files by process. How about yet another? Pathopens.d tracks files by the path, and the count. Here's what the output might look like:
COUNT PATHNAME
1 Leopard/.
2 /dev/dtracehelper
2 /dev/urandom
2 /usr/share/locale/en_US.UTF-8/LC_COLLATE
2 /usr/share/locale/en_US.UTF-8/LC_CTYPE
2 /usr/share/locale/en_US.UTF-8/LC_MESSAGES/LC_MESSAGES
2 /usr/share/locale/en_US.UTF-8/LC_MONETARY
2 /usr/share/locale/en_US.UTF-8/LC_NUMERIC
2 /usr/share/locale/en_US.UTF-8/LC_TIME
24 /dev/
Open /usr/bin and explore some of the other d scripts. While not all of the dscripts are there, most are.
One last thing, Brendan Gregg has provided a whole range of one-liners, most of which work on Leopard. Here's their location: http://www.brendangregg.com/DTrace/dtrace_oneliners.txt. Troubleshooting problems with these tools is now so much easier. I've already solved some problems I previously couldn't seem to solve.
Well, that's about it for this month. Play with these new command line tools, as they really increase the arsenal available to any Macintosh system administrator. Until next month, I'll see you on the lists!
Philip Rinehart is co-chair of the steering committee leading the Mac OS X Enterprise Project (macenterprise.org) and is the Lead Mac Analyst at Yale University. He has been using Macintosh Computers since the days of the Macintosh SE, and Mac OS X since its Developer Preview Release. Before coming to Yale, he worked as a Unix system administrator for a dot-com company. He can be reached at: philip.rinehart@yale.edu.
The MacEnterprise project is a community of IT professionals sharing information and solutions to support Macs in an enterprise. We collaborate on the deployment, management, and integration of Mac OS X client and server computers into multi-platform computing environments.
