When programs and services run on your system, they are programmed to give some sort of indication of what they are doing, either through a graphical interface or some added function for the system. Since no program is perfect, programmers build in logging routines that indicate when specific tasks are done, or at least tried, by their programs.
The Console in OS X is a utility that allows you to see some of these ongoing messages the system and running applications are outputting, by allowing you a central location to access log files generated by system services and applications.
The Console utility is split into three parts, some of which are redundant.
- System Log Queries
This is a feature of the console that gives you access to the main “system.log” file. Since this file logs the activity of background processes that keep the system running, it is given a specially place as the first category in the Console program. Under the “System Log Queries” section is the main “All Messages” query, which shows everything in the system log.In addition to “All Messages,” you can add your own query to filter the system log. For example, if you would like to search for any message from the Security Server process that contains the word “auth” (often tructated for authentication activity), then you can do so by choosing “New System Log Query” from the File menu and then adding the criteria to specify the message as “auth” and the sender as “com.apple.SecurityServer” (see the screenshot).
- Diagnostic and Usage Information
While the system log is a view of ongoing activity with the system, the Diagnostic and Usage Information section contains information on system and application hangs, crashes. If a program crashes, the system’s crash reporter will generate a file that contains potential causes why this might have happened, and these will be available in this area. The User diagnostic reports will be for programs that are running within your user account, and the System diagnostic reports will be for more global programs and system services.While these reports may appear cryptic, they can be exceptionally useful for a technician to help diagnose a problem with your system. At most, you might need to find the most relevant one to send to a tech. Luckily, these reports are tagged with a date and time in their name, so if a program you use is crashing regularly, then you can locate the most recent crash reports for it so they can be analyzed.
This section contains links to the raw log files at their various locations on your hard drive. The file at the top of this list is the “system.log” file, which is a link to the /var/log/system.log file on the system. Clicking this will give you the same information as is shown when you click “All Messages” under the “System Log Queries” option; however, being a link to the file, as with all files listed here, you can right-click it to reveal it in the Finder.Next are the individual user log files, located in the current user account at the ~/Library/Logs/ folder. The contents of this directory are generally errors, status, and warnings for various user-launched programs and services.
Last is the system log folder, which is at the hidden /var/log/ directory. This contains the output information for various background services like the system firewall, authentication services, printing routines, system updates, and system configuration changes. The “system.log” file that is referenced in the above locations is also located here.
Using the Console
While you can look up various logs and peruse them for past actions and situations that the system has encountered, you can also use the console to actively troubleshoot the system, or at least help you isolate problems. To do this, first focus on just the relevant logs. These include the “system.log” file, which can most functionally be accessed through the “All Messages” section.
Next, locate the specific application or service log. This step can be a bit challenging, but takes perusing the various log files and locating the ones that represent the service or program you are running. For instance, the “wifi.log” file contains output from the “airportd” background process, for displaying changes to the network configuration.
With these located, you can isolate relevant log messages for a problem or action at hand by performing the following routine:
- Quit all programs except the one that’s giving you problems.
- Select the desired log file
- Click “Clear Display” or “Insert Marker” in the Console toolbar.
- Go to the problematic program and perform the action that is giving you problems
- Return to the Console to see if any logged errors seem relevant to your problem.
This process is a bit general, but if you repeat it several times (both with the system log and with relevant application logs) then you may start seeing a pattern of what logged messages correspond to the actions you are performing on your system. As such, while straight-forward, this process is not a guaranteed way to get information about a specific problem, but can help if you have a keen eye for detail.
How do you view the log(s) of a different machine?
For example, perhaps the GUI is frozen on another machine, but you can still SSH into it (a subject for another MacIssues post).
Or is there a way to get the Console application to view remote logs?
You will have to either log in via SSH, or use screen sharing, or be at the machine locally. There is no built-in service (that I know of) to view the logs on one system with another. For a system that is hung up, sometimes you can still log in with screen sharing using another account, but if not, then SSH will have to do. Via the terminal, the use of the “tail” command is the most convenient method I know of, but there are other options to search (combinations of grep, cat, or open in an editor, etc.).
IF you (a) know which log file in the remote Mac contains the info you want to view, AND (b) have “read” access to that file from the local machine, THEN you can simply open that file using the Console application in the local machine.
Of course those are unlikely “IF’s” but if you can figure them out by looking at the logs in the local machine it may work for you.