To view the information contained in a trace log, you must dump the log. You can dump a kernel log to standard output or to a file; you can also continuously dump a kernel log. You can dump a server process log to a file only. To dump a trace log, do the following:
1. Verify that you have the necessary privilege. To dump a kernel log, you must be logged in as root on the local machine. To dump a server process log, you must be listed in the administrative list associated with that process on the corresponding machine; if necessary, issue the bos lsadmin command to check.
2. Issue the dfstrace dump command to dump each specified log:
$ dfstrace dump [{-set set_name... | -follow log_name}] [-file output_filename]
[-sleep
seconds_between_reads] [-cdsentry server_entry_in_CDS]
The -set set_name option specifies the name of each event set whose corresponding logs you want to dump. Specify this option or the -follow option; omit both to dump all kernel logs on the local machine or all server process logs for the server process specified with the -cdsentry option. If you specify multiple event sets that point to the same log, that log is dumped multiple times.
The -follow log_name option specifies the name of a kernel log to continuously dump. Process server logs cannot be continuously dumped. When a log is continuously dumped, it is also cleared. Specify this option or the -set option; omit both to dump all kernel logs on the local machine or all server process logs for the server process specified with the -cdsentry option.
The -file output_filename option indicates the name of a file to which to write the output of the command. If the log being dumped is a server process log, the output_filename cannot contain slashes (/); the file is automatically placed in the directory dcelocal/var/dfs/adm. Furthermore, if an output_filename is not provided, the output is placed in the file icl.server_process_name. Server process logs cannot be directly dumped to standard output. (If the output file for a server process log already exists, the older version is moved to the file output_filename.old.) If the log being dumped is a kernel log, the output_filename must specify the full or relative path name of the output file.
The -sleep seconds_between_reads option defines the number of seconds that the command pauses between dumps when dumping a kernel log in continuous mode. This option can only be used with the -follow option. The default value is 10 seconds.
Note: Sending a SIGUSR1 signal to a server process that supports tracing is another way of directing the server process to dump the contents of its logs in the file dcelocal/var/dfs/adm/icl.server_process_name. This is the only way to dump the logs associated with the dfsbind process because this process does not support an RPC interface.
At the beginning of the output of each dump is the date and time at which the dump began. Unless the -follow option is specified, the number of logs being dumped is displayed. The content of each log is preceded by a message identifying the log.
Each log message contains the following three components:
· The timestamp associated with the message
· The process ID or thread ID associated with the message
· The message itself
Every 1024 seconds, a current time message is written to each log if there is message activity in the log. This message has the following format:
time timestamp, pid 0: Current time: unix_time
Use the current time message to determine the actual time associated with each log message as follows:
1. Locate the log message whose actual time you want to determine.
2. Search backward through the dump record until you come to a current time message.
3. If the current time message's timestamp is smaller than the log message's timestamp, subtract the former from the latter. If the current time message's timestamp is larger than the log message's timestamp, add 1024 to the latter and subtract the former from the result.
4. Add the resulting number to the current time message's unix_time to determine the log message's actual time.
Because log data is stored in a finite, circular buffer, some of the data can be overwritten before being read. If this happens, the following message appears at the appropriate place in the dump:
Log wrapped; data missing.
Note: If this message appears in the middle of a dump, which can happen under load, it indicates that not all of the log data is being written to the log. Increasing the size of the log with the dfstrace setlog command may alleviate this problem.
The following command dumps the log used by the cm kernel event set on the local machine:
# dfstrace dump cm
DFS Trace Dump -
Date: Fri Oct 8 10:18:02 1993
Found 1 logs.
Contents of log cmfx:
Log wrapped; data missing.
time 520.211319, pid 25135: found a princ 62b4144 ref 3
time 520.211355, pid 25135: find a princ (fast path) 62b4144, ref 3
time 520.211387, pid 25135: fshs_GetPrincipal END 62b4144, ref 3
time 520.211411, pid 25135: fshs_PutPrincipal 62b4144 ref 3
time 520.219153, pid 25135: Lookup 8005a4d.81c6c35.0.3fe/param.h, flags 0x1
time 520.219440, pid 25135: fshs_GetPrincipal START
time 520.219483, pid 25135: fshs_GetHost, cookie 667de00
time 520.219511, pid 25135: fshs_FindHost, cookie 667de00
time 520.219559, pid 25135: find a prime host 62a2068
time 520.219590, pid 25135: find a host in fast path 62a2068
time 520.219625, pid 25135: fshs_FindPrincipal ..
time 715.203951, pid 0: Current time: Mon Sep 20 13:05:15 1993
time 717.969835, pid 24621: fshs_GetPrincipal START
time 717.969881, pid 24621: fshs_GetHost, cookie 66eed80
time 718.969910, pid 24621: fshs_FindHost, cookie 66eed80
time 718.969959, pid 24621: find a prime host 62a2068