Built-in Diagnostic and Repair Tools

 < Day Day Up > 

Monitoring Tiger System Operation

Beneath the shiny blue Aqua buttons and metallic skin of the Finder, there are dozens of processes and supporting subprocesses that manage your computer. If a problem that affects system operation occurs, chances are there is some sort of audit trail that can lead you to the culprit.

In this section, we will look at how you can monitor the inner workings of your operating system and computer from developing a baseline for a properly functioning machine to viewing logs and customizing the configuration of the system logging daemon itself.

Creating an Overview of Your System: System Profiler

The Apple System Profiler (path: /Applications/Utilities/System Profiler) is a tool for browsing the hierarchy of components in your computer, connected to your computer, and installed on your computer. This information can be useful in developing a baseline profile that can be compared against a profile of a "sick" system.

To clarify, consider that most computers just "work" or we'd be writing 28 chapters on system troubleshooting and 1 chapter on operation. After a user has configured a working system and is happy with how it operates, a baseline is developed. This baseline includes all the functional parameters for the machine: hardware configuration, software installations, and so forth. If the machine stops working correctly at sometime in the future, it is very likely that something has changed. A comparison of the original baseline to the current configuration can help determine what has changed and give the user an idea of what must be done to fix the problem. System Profiler can create and save full profiles of virtually every system setting in Tiger, giving you the flexibility to analyze working versus nonworking machines without relying on what a user might or might not have installed or changed on the system.

System Profiler collects information about your computer when initially launched. Information is divided into four major categories (labeled Contents): Hardware, Software, Network, and Logs. The categories are listed in a pane on the left side of the window. In the initial display, Hardware is highlighted, providing an overview of your system hardware, as shown in Figure 29.8.

Figure 29.8. System Profiler collects and displays your system's hardware configuration.

Each of the categories can be expanded or collapsed by clicking the disclosure arrow in front of the topic. Disclosure arrows are used extensively throughout the application, so be sure to click around you'll be surprised at the total amount of available information.


The View menu offers the capability to switch between three levels of reported information (Mini, Basic, and Full). The information in this section assumes that Full (Command-3) has been selected.


The Hardware category, displayed in Figure 29.8, contains a summary of the base computer. By expanding Hardware to show each of the subtopics, you can find everything from the serial and sales order number assigned when your machine was first built to the vendor IDs of devices plugged in to your USB bus.

For example, to see the internal disks and ATA (Advanced Technology Attachment) storage devices, click the ATA hardware category. The content area of the screen refreshes with a list of devices at the top and a detail view of the selected device at the bottom. Figure 29.9 shows an example of this screen.

Figure 29.9. View details of a given piece of hardware.

If you're unfamiliar with the standard Macintosh bus types, this list might provide some insight:

  • USB Universal Serial Bus. In its initial implementation (version 1), USB is a slow (12Mbps) bus used for connecting external peripherals such as low-speed storage, scanners, printers, cameras, mice, and keyboards. USB 2.0, now included on new Macs, supports much faster speeds and can be much like FireWire.

  • FireWire An Apple-developed bus technology that supports speeds of 400Mbps and 800Mbps, hot-swappable devices such as high-speed storage, and digital-video cameras. The FireWire bus is also known by its IEEE name, 1394, and as Sony's iLink.

  • PCI Peripheral Component Interconnect. The PCI bus was developed by Intel (yes, that Intel) and is the standard for connecting internal video cards, sound cards, and so on.

  • ATA Integrated Drive Electronics. The IDE standard was developed by Western Digital and is used for internal CD-ROM and disk storage.

  • Parallel SCSI Small Computer System Interface. A fast bus for high-speed storage devices, typically used on server-class computers.

  • Serial ATA The current high-speed ATA standard for drives shipped in new Apple computers. This is another PC standard that Apple has successfully adopted.


Selecting the Software profile category displays information about your Tiger system configuration, including version, kernel, boot volume, and active user. You can use the three categories within Software to display extended information about installed components of the operating system.

  • Applications The Applications selection scans your drive to display all the installed applications (the BSD subsystem is not taken into account). You can view version, creator, and modification dates in the upper pane. Selecting an entry in the list displays details, including location, in the bottom pane.

  • Extensions Extensions, like frameworks, provide functionality to the operating system. Unlike frameworks, they work directly with the hardware to enable the operating system to access devices such as network cards, sound cards, and other components. Mac users are familiar with extensions. In Mac OS 8 and 9, extensions had similar capabilities but often made the operating system unstable. In Mac OS X, the Classic extension is replaced by a .kext (kernel extension). These plug-ins for the Mach kernel cannot be installed by unprivileged users and are no longer appropriate for creating cool (but crash-causing) additions to the system.

  • Fonts Identifies the available fonts that are installed in your Tiger distribution, along with each font's full name, creator, and family/style information.

  • Frameworks A framework is a collection of shared object libraries. Instead of each application reimplementing code, the operating system can provide commonly used functions in the form of a shared library. There are dozens of frameworks in the base installation of Tiger ranging from AppleShare to Speech Recognition.

  • Logs The Logs category enables you to view recent activity in a number of Tiger logfiles. This functionality is replicated in a number of locations, such as the Console utility (which you'll learn about shortly), so its inclusion here is a bit curious.

  • Preference Panes Displays the System Preference panes that are installed on your machine along with their visibility status.

  • Startup Items Provides an overview of all the Tiger StartupItems, the order in which they are started, and the services they provide.


The Network category provides an overview of your installed network configurations, their interface IDs, and IP addresses (if any), as shown in Figure 29.10. Selecting a configuration displays additional information including MAC (Media Access Control) address and subnet mask in the lower details pane.

Figure 29.10. The Network category gives you a quick overview of your network status.

Within the network category are several subcategories for an even greater depth of information:

  • AirPort Card Provides specific information about any AirPort (original or extreme) hardware that is installed.

  • Firewall Provides a view of the ipfw firewall status and rulesets.

  • Locations Lists any defined network locations and the parameters for their use.

  • Modems Displays information about any built-in modem, the standards it uses, and basic manufacturer/driver information.

  • Volumes Identifies active network volumes and the protocols they are using.

Exporting System Profiler Information

When diagnosing a system problem, it is often useful to have all the configuration information with you. If you aren't sitting in front of the problem computer or need someone else to diagnose a problem remotely, you'll have to get information out of System Profiler and into another machine.

To do this, use File, Save As to save in either plain text, RTF, or XML formats. The advantage of an XML-based System Profiler document is that it can be opened on another Tiger system and viewed as if it were the local computer.


Tiger's System Profiler adds an option under the File menu for sending the contents of a profile to Apple. There should never be a need to do this unless you're requesting computer support from Apple.

Running System Profiler from the Command Line

In the event that you need to perform a remote diagnosis, System Profiler can even be run from the command line with system_profiler. For example, to generate a mini report (rather than a basic report or a full report), I could use system_profiler -detailLevel mini:

 brezup:jray jray $ system_profiler -detailLevel mini Hardware:     Hardware Overview:       Machine Name: Power Mac G4 Cube       Machine Model: PowerMac5,1       CPU Type: PowerPC G4  (2.9)       Number Of CPUs: 1       CPU Speed: 500 MHz       L2 Cache (per CPU): 1 MB       Memory: 768 MB       Bus Speed: 100 MHz       Boot ROM Version: 4.1.9f1 ... 

Likewise I could use the basic or full keyword to generate more verbose output.

To limit the display to a certain type of data, the -listDataTypes option can be useful. This option lists all the types of information that can be displayed, which, in turn can be specified on the command line as an option to software_update. For example, SPNetworkDataType is a known data type that displays network information:

 brezup:jray jray $ system_profiler SPNetworkDataType Network:     Internal Modem:       Type: PPP (PPPSerial)       Hardware: Modem       BSD Device Name: modem       Has IP Assigned: No       IPv4:           Configuration Method: PPP       IPv6:           Configuration Method: Automatic       Proxies:           Proxy Configuration Method: Manual           ExcludeSimpleHostnames: 0           FTP Passive Mode: Yes           Auto Discovery Enabled: No ... 

Finally, you can also export the System Profiler data directly into an XML file compatible with the GUI application by using the -xml option and redirecting the output to a file with the extension .spx:

 brezup:jray jray $ system_profiler -xml -detailLevel full > systemreport.spx 

A summary of the system_profiler options and their use is provided in Table 29.6.

Table 29.6. System Profiler Can Be Easily Controlled from the Command Line




List all the available data types for the purpose of limiting information.

<data type> ... <data type> ...

When data types are specified on the command line, the report output is constrained to those elements.


Output the results in a System Profiler compatible XML file. (The .spx extension must be used.)

-detailLevel [mini|basic|full]

Choose the level of detail in the output report.

Understanding Tiger Logfiles and Apple System Logger

Almost every server process on your computer generates a logfile. What is logged, and when, is up to the software writing to the log. A centralized process, called syslogd, manages the incoming log data from other applications and directs it to the system console, files, or remote syslogd servers. In previous versions of Mac OS X, syslogd was directly based on the BSD version of the server. In Tiger, syslogd is now known as the Apple System Logger (ASL) and provides support for many additional features that, unfortunately, aren't well documented at this time.

Many applications send data to syslog, some to syslog and local logfiles, others only to local files. Apple's goal in introducing ASL is to provide a better logging facility that can be used by Unix applications as well as native Mac OS X programs. We're still a long way from keeping everything in one place. Our first priority will be to get you familiarized with the primary Tiger logfiles as they are initially configured on your computer.

Tiger, like other Unix systems, uses /var/log/ as its primary repository for logfiles. Apple has also chosen to create /Library/Logs, and ~/Library/Logs for a handful of other Apple-specific logfiles and /Library/Receipts for logs of installed software.


Logfiles, by their nature, log things. In doing so, they use up drive space. It is common practice to use a separate partition for /var/logs (or reconfigure system processes to log to a different drive) so that an attacker can't fill up a volume with logfile entries, thus disrupting processes that are attempting to store critical data on the same drive.

So, what is stored on your system? Table 29.7 lists the common default Tiger logfiles, their location, and what they contain.

Table 29.7. Tiger Default Log Locations




Apple's new ASL system log location in Tiger. This is almost identical to /var/log/system.log but uses a new, more readable format for storing information.


The cups directory contains access_log, error_log, and page_log providing information on access to the CUPS web interface, errors encountered by the CUPS process, and a print job log, respectively.


Identifies application crashes and the location where crash information was saved.


This directory contains logs of the Tiger fax system usage.


Logs login/logout information from the Tiger FTP server lukemftpd.


The httpd directory contains a web server access_log with each Apache request, and an error_log containing errors reported by the server process.


A log of firewall activity. This log will only accumulate data when your firewall is active.


Similar to /var/log/wtmp; this log identifies the last time a user logged in (binary logfile).


Historically, the location for errors from the lookupd process. lookupd, however, does not use this file in Tiger, and it should remain empty (unless configured otherwise in NetInfo) on your system. Instead, lookupd logs to syslog, which places lookupd messages in /var/log/netinfo.log.


Logs print requests made via lpr.


Contains Postfix errors and message delivery logs.


Includes messages logged from the netinfod the central repository for user/group/host information on your computer. Also contains error messages logged by lookupd.


The samba log directory contains the log.smbd and log.nmbd files, which contain access and error messages from the Samba file server, and the Samba NetBIOS name server, respectively.


Logs authorization failures, such as failed FTP logins.


Contains operating system notices, authorization failures, errors, and other logging goodness get stored in the main Mac OS X system.log. This logfile might be phased out in favor of /var/log/asl.log in Tiger.


The Apple Directory service logs (DirectoryService.server.log and DirectoryService.error.log) log messages and errors related to Apple's directory service architecture BSD files, NetInfo, LDAP, and so on.


Consists of detailed logs containing application-specific crash information for use in troubleshooting software instability.


AppleFileServiceAccess.log and AppleFileServiceError.log record logins and errors in the built-in AppleShare server. The access log is not enabled by default.

/Library/Logs/Software Update.log

Logs all automatic updates performed via the Software Update preference panel.


Contains a history of user logins/logouts and system restarts. This is a binary logfile and is viewable with the last and ac commands.


Stores information related to the operation of the windowserver process that manages the GUI.


Stores the currently logged-in users.

Looking at this list, you might be wondering, "Why are logs for multiple services showing up in a single logfile?" or "Why are multiple logfiles used for a single service?"

Remember that many processes log their output via a centralized process called syslog. Messages that are sent to syslog can be stored in multiple locations and directed to different logfiles depending on their level a 32-bit value that contains an encoded facility and level. As you add new Unix software to your computer, you'll find that many applications can and do log via syslog and the only real way to know what is going where is to understand how syslog works, and how you can configure it, which we'll cover in the next section.


Many of the Tiger logfiles are rotated on a daily, weekly, or monthly basis by the files /etc/daily, /etc/weekly, and /etc/monthly, respectively. To view the contents of a file that has been rotated out of use, you need to unzip it (gunzip <filename>) first.

In some cases, you might want to disable the rotation altogether or change it so that it operates at a different interval. You can do this by either commenting out or simply moving the appropriate portions of the daily, weekly, and monthly files. This code (in /etc/daily), for example, rotates the /var/log/system.log files:

 cd /var/log for i in system.log; do     if [ -f "${i}" ]; then         printf %s " ${i}"         if [ -x /usr/bin/gzip ]; then gzext=".gz"; else gzext=""; fi         if [ -f "${i}.6${gzext}" ];             then mv -f "${i}.6${gzext}" "${i}.7${gzext}"; fi         if [ -f "${i}.5${gzext}" ];             then mv -f "${i}.5${gzext}" "${i}.6${gzext}"; fi         if [ -f "${i}.4${gzext}" ];             then mv -f "${i}.4${gzext}" "${i}.5${gzext}"; fi         if [ -f "${i}.3${gzext}" ];             then mv -f "${i}.3${gzext}" "${i}.4${gzext}"; fi         if [ -f "${i}.2${gzext}" ];             then mv -f "${i}.2${gzext}" "${i}.3${gzext}"; fi         if [ -f "${i}.1${gzext}" ];             then mv -f "${i}.1${gzext}" "${i}.2${gzext}"; fi         if [ -f "${i}.0${gzext}" ];             then mv -f "${i}.0${gzext}" "${i}.1${gzext}"; fi         if [ -f "${i}" ]; then               touch "${i}.$$" && chmod 640 "${i}.$$" &&                      chown root:admin "${i}.$$"               mv -f "${i}" "${i}.0" && mv "${i}.$$" "${i}" &&                if [ -x /usr/bin/gzip ]; then                  gzip -9 "${i}.0"; fi         fi     fi done 

To change the rotation, simply move these lines to a script that is executed at a different interval or comment them out.

Using syslogd

The ASL daemon can be a bit confusing for users coming from other platforms or migrating from earlier versions of the Macintosh. The first point to understand is that syslogd is not generating the messages that are showing up in your logfiles. It provides a logging system that other software can take advantage of, rather than that software having to write its own files similar to the Event Viewer in Microsoft Windows. ASL can redirect incoming log information to remote syslogd servers, the console, logged-in users, and, of course, files providing far more flexibility to developers than if each had to develop logging functions independently. The second point is that syslogd-generated files are often configured to be "message-centric" rather than "application-centric," meaning that logs contain a similar type of message (failed logins, perhaps) from multiple different daemons, rather than multiple messages from a single daemon.


In centralizing the system's logging, ASL also presents a single point for disrupting critical log messages for attackers. As you'll see shortly, syslog could easily be configured to dump high-level messages to /dev/null.

Understanding Facilities and Levels

To configure syslogd, you first need to understand the vocabulary of the logging system. There are four terms used by syslog, its documentation, and our discussion that you must understand before proceeding:

  • Facility An identifier for the portion of the system that is sending the log entry to syslog, such as the kernel, mail, or FTP processes.

  • Level A ranking of the importance of the incoming log message, from simply informational notifications to emergency warnings.

  • Selector A combination of one or more facilities and levels that are matched against log messages coming into syslog. If the selector matches the level and facility of the message, syslog executes an action.

  • Action A syslog action determines what happens to an incoming log message if it matches a selector in the configuration file. Actions can write to files and devices, forward the messages to remote log servers, and notify logged-in users.

Levels and facilities are not arbitrary values that the user determines; the syslog daemon defines them. Table 29.8 provides the documentation for the available facilities as found in man 3 syslog.

Table 29.8. Syslog Logging Facilities

User-Level Name

Direct Name

Logging Purpose



Kernel messages



User-level messages



Mail system



System daemons



Security/authorization messages



Internal syslog messages



Line printer subsystem



Network news subsystem



UUCP subsystem



Clock daemon



Security/authorization messages (private)



FTP daemon



NetInfo daemon



Remote authentication/authorization



Logs an info message every 20 minutes

What facility a program uses to log is determined not by syslogd but by the application itself. You should check the documentation of your software to determine what facilities are used, and how to change them if you want to do so.

Note that there are user-level facility names and direct facility names. You'll use the short user-level names when configuring syslogd actions for each facility, but will likely need to use the direct name (which maps to an internal constant) when configuring which facility individual daemons are logging to.

Like there are different facilities, there are also a number of predefined levels that can be sent to syslogd with a log message. Levels indicate the nature of the incoming message, and are found in man 3 syslog. Table 29.9 documents the syslogd levels ranked from most to least serious.

Table 29.9. Syslogd Levels

User-Level Name

Direct Name

Level Meaning

emerg or panic


System is unusable



Action must be taken immediately



Critical conditions

err or error


Error conditions

warn or warning


Warning conditions



Normal but significant condition






Debug-level messages



No priority

Fine-tuning /etc/syslog.conf

The syslogd process is configured via /etc/syslog.conf a simple text file that matches selectors (facilities and levels) with an action to perform.

A selector is written as <facility>.<level>, where the values are taken from Tables 29.8 and 29.9. An asterisk (*) can be substituted for the facility and/or level to match any facility (except mark) or level.


The level in a selector is the base level for a match. All levels equal to (or greater than) the base level are matched.

Actions are can consist of any of the following:

  • A path to a logfile (for example, /var/log/ftp.log)

  • A remote syslog server specified with the syntax @<hostname or ip> (for example, @

  • A device (for example, /dev/console)

  • A comma-separated list of usernames (for notifying users logged in via terminal sessions) or an asterisk (*) to notify everyone

For example, to log all messages logged to the ftp facility at the level of error or higher to the file /var/log/ftperror.log, you would use a line like this:

 ftp.error                                 /var/log/ftperror.log 


The selector and action must be separated by a tab. If spaces are used, the entry will not work.

If you want multiple selectors to log to the same file, you can use multiple /etc/syslogd.conf lines, or add multiple selectors to a single line by separating them with semicolons. For example, to log all authentication information to the console, you could write:

 authpriv.*;remoteauth.*            /dev/console 

The asterisk can also be applied to the facility in a selector to select all facilities at a particular level. This can be combined with the none level to exclude certain facilities from the selector. For example, you could use the following line to log all errors except those coming from the mail facility:

 *.err;mail.none                /var/log/allerrorsexceptmail.log 

A final shortcut is to write multiple facilities that share the same selector as a comma-separated list with only the last facility also containing a level, such as ftp,mail,netinfo.error, which is the same as writing ftp.error;mail.error;netinfo.error.

The default Tiger syslogd.conf file should look very similar to this:

 *.err;kern.*;auth.notice;authpriv,remoteauth.none;mail.crit/dev/console *.notice;*.info;authpriv,remoteauth,ftp.none;kern.debug;mail.crit/var/log/system.log # Send messages normally sent to the console also to the serial port. # To stop messages from being sent out the serial port, comment out this line. #*.err;kern.*;auth.notice;authpriv,remoteauth.none;mail.crit /dev/tty.serial # The authpriv log file should be restricted access; these # messages shouldn't go to terminals or publicly-readable # files. authpriv.*;remoteauth.crit                              /var/log/secure.log lpr.info                                                /var/log/lpr.log mail.*                                                  /var/log/mail.log ftp.*                                                   /var/log/ftp.log netinfo.err                                             /var/log/netinfo.log install.*                                               /var/log/install.log local0.*                                                /var/log/ipfw.log *.emerg                                                 * 

As you can see, many of the logfiles mentioned earlier are created via syslog, and the system.log file and console contain selectors that will capture messages from all available facilities. This causes in some of the redundancy you might see when viewing the logs.


Any changes to /etc/syslogd.conf can be put into effect immediately by sending the -HUP signal to the syslogd process (killall -HUP syslogd).


Apple does not include the output of TCP Wrappers in any of the default logs. If you use TCP Wrappers (which logs to the syslog facility), you might consider adding this line to /etc/syslog.conf:

 syslog.err                                  /var/log/secure.log 

Creating a Network syslogd Server

Creating a centralized network ASL server can help get you keep an eye on all your systems without having to directly watch dozens of different machines and files. To do this you must add either -udp_in 1 or -u as an argument to syslogd.

This change has to be added directly to the file where syslogd is invoked. In the case of Tiger, this is /System/Library/LaunchDaemons/com.apple.syslogd.plist. The line


should be modified to read

 <string>/usr/sbin/syslogd -udp_in 1</string> 

Client machines can now be configured to send syslog messages to the centralized server. The default Tiger /etc/syslog.conf could be rewritten to send its logs to a log server at like this:

 *.err;kern.*;auth.notice;authpriv,remoteauth.none;mail.crit/dev/console *.notice;*.info;authpriv,remoteauth,ftp.none;kern.debug;mail.crit@ # Send messages normally sent to the console also to the serial port. # To stop messages from being sent out the serial port, comment out this line. #*.err;kern.*;auth.notice;authpriv,remoteauth.none;mail.crit/dev/tty.serial # The authpriv log file should be restricted access; these # messages shouldn't go to terminals or publicly-readable # files. authpriv.*;remoteauth.crit                                  @ lpr.info                                                    @ mail.*                                                      @ ftp.*                                                       @ netinfo.err                                                 @ install.*                                                   @ local0.*                                                    @ *.emerg                                                 * 

Thankfully, syslog-written logs contain the hostname of the machine generating the message. Logs follow the format:

 <time stamp> <host generating message> <process name> <log message> 

This enables an administrator to quickly grep through the contents of a combined logfile for a specific machine's messages.

Whether you choose to create a centralized server for a network for simply monitor the activity on your personal computer, a knowledge of syslogd will help make it easier.


Unfortunately, knowing how to use syslogd isn't going to help you read and analyze your logs. The messages that are written to the logging daemon are arbitrary; they're determined by the program that sends them. The facility and level are also arbitrary, which can lead to log messages that you don't necessarily feel are appropriately classified, but the author did.

Monitoring Console and Log Output: Console

The Tiger GUI hides a tremendous amount of operation information from the user. You've seen that this information is often sent to a number of logfiles. In some cases, however, it is not stored in a file, but sent to a device called the console (/dev/console). On some Unix systems, the console actually is a separate device, such as a VT100 terminal display. On Mac OS X, it exists as a virtual device and is responsible for reporting information as it arrives.

The Console application (path: /Applications/Utilities/Console) enables you to watch console-directed error and status messages as they appear. If your computer appears to be stalled or is acting in an unusual manner, Console might be producing information that can help debug the problem. Figure 29.11 shows the Console application.

Figure 29.11. The Console application shows internal system error and status messages as they appear.

Even on a properly working Tiger system, Console displays error and warning messages related to day-to-day application use. This shouldn't be taken as an indication of a problem, but rather as a demonstration of how closely you can trace your system's operation.

Managing the Log View

To filter the Log view, use the filter field in the upper-right corner to enter a string that each line must match to be displayed. For example, to display information from the Safari web browser, you would type Safari.

To clear the filter, either remove the string or click the X icon at the end of the field.

You can also use the toolbar icons to mark the log, which enters a time stamp into the log display, or to clear the display entirely. This does not modify the actual logfiles, just the information display. To reload the full log at any time, click the Reload button, or use File, Reload (Command-R).


Additional functions (such as a full Find pane) can be added to the toolbar using View, Customize Toolbar.

Viewing Other Logfiles

The Tiger system maintains a great deal of log information in addition to what is sent directly to the console. Logs are stored in three key locations: your home directory (~/Library/Logs), the system log directory (/Library/Logs), and the BSD log directory (/var/log).

The Console application can display the contents of any of the logfiles we've discussed in this chapter (or any other). To view an arbitrary logfile, choose File, Open from the menu, and then drill down through the filesystem until you locate the file you want.

An alternative way to locate logfiles is to click the Logs button in the toolbar or choose View, Show Log List from the menu. This opens a pane on the left side of the window with lists of logs in each of the three primary locations, as shown in Figure 29.12.

Figure 29.12. Browse other logs on your system.

Use the disclosure arrows to browse to the logfile that you want to view, and then select its name to display the file's contents. You can also choose File, Open Quickly to select one of the recognized logfiles for display.


If you choose a zipped (.gz) logfile, the Console application will automatically decompress it for viewing.

To save a copy of the entire log you are viewing, or a portion of it, choose File, Save a Copy As or File, Save Selection As (Option-Command-S), respectively.

Getting Notified When a Log Changes

Use the Console application preferences to set how (and if) you will be notified when a logfile window changes. Click Bounce Icon When Log Is Updated to cause the Dock icon to bounce when there are incoming messages.

If you'd prefer to immediately view the log itself, clicking the Bring Updated Log Window to Front check box causes the application to appear and display the new information. The Send Back slider is used to set the length of the delay before the Console application hides itself.


The new Tiger ASL utility syslog can also be used for viewing as well as managing log files. syslog provides direct access to the ASL logs and can watch (-w), filter (-k), or even clean out (-p) the logs.

     < Day Day Up > 

    Mac OS X Tiger Unleashed
    Mac OS X Tiger Unleashed
    ISBN: 0672327465
    EAN: 2147483647
    Year: 2005
    Pages: 251

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net