Tech Note 003
Title: Troubleshooting guidelines (3) - Setting debug to create error logs
Updated: April 2005
 

About debug logs
If you have a problem with an operation, and you refer it to your AXI or Xinet/SGL support staff, you will probably be asked to run the operation with debug enabled so that an error log is generated.
A normal FlashNet process log contains lines of messages that are generated by FlashNet as it progresses with the operation. These messages provide information that is useful to the user, such as when a volume is being loaded into the drive or when index information is being created. When debug is enabled, a debug log is created in addition to the standard process log. A debug log (known also as an error log) is a text file containing code-level information that displays actual commands initiated by FlashNet. The debug log is used by SGL engineers to closely examine the commands that were initiated at the time that the failure occurred, and the messages that were received in turn from the backup device.
Debug logs usually contain lots of information, far more than a standard process log. For this reason, they may become quite large, particularly if the operation was performed on a large data set. It is possible for debug logs to reach several hundred megabytes in file size, so when setting debug you should ensure that you have enough free disk space on the FlashNet server. If the operation that you are requesting uses a fairly small data set the debug log will not be very large.

Debug logs are created in the directory /<FlashNet_home>/error_logs. The name of each debug file is errorx_yyyy.log, where x is a number and y is the number of the process id. x increments each time a new log is created, e.g. the first log in the directory is called error1_yyyy.log, the second error2_yyyy.log and so forth. If you delete error logs the next one created will be the lowest number not yet created, e.g. if you delete all logs error1_yyyy.log will be the next file created.
If you are unsure as to the error log that was created by the operation, the first line of the standard process log displays the path to the error log:
17:28:I044: Using error log file /usr/FlashNet5/error_logs/error6_1073.log
Each log is a text file. If requested by support engineers, you can use the Unix commands head and tail to strip out only the required parts of the log.
 
Setting debug using the UI
Debug can be set in several ways, depending on the type of operation that requires an error log. The easiest way to set debug is in the UI. If the operation that fails is:
a backup or archive operation initiated using the Online Backup window; a scheduled backup or archive that executed at the specified time or was initiated using the Execute Now command in the Scheduler window; or a Restore operation executed from the Restore window
then you should set the Create Debug option in the Online Backup or Restore window and re-try the operation. In the case of a schedule, you must load the schedule into the Scheduler window, enable the Create Debug File option, and save the schedule. You can then either wait for the schedule to execute again when the scheduled execution time arrives, or you can run it immediately using the Options > Execute Now command. Once the schedule has completed and the debug log has been created, remember to remove the Create Debug File option from the schedule and save the schedule again.
 
Setting debug using the environment file
Debug can also be set globally for all FlashNet processes using FlashNet's environment file, /.dtool_env. Adding the entry
DS_DEBUG 99
to this file enables debug for all FlashNet operations, including any schedules that execute, and any job that are initiated via FlashWeb (using this setting in dtool_env is the best way to set debug for FlashWeb archives or restores). This means that if you have several FlashNet and FlashWeb processes executing while the entry is present, multiple debug logs will be created. It's a good idea when using debug in the environment file to try and limit the number of operations that are executed while the entry is present, ideally so that only the operation that you wish to debug is executed. Otherwise it can be tricky finding the correct error log for your process.
When you have created a debug file for the relevant process, make sure that you edit the file /.dtool_env to remove the DS_DEBUG entry and prevent further debugging.
 
Setting debug for command line operations
If you use dtool from the command line, you can set debugging for an operation using the D99 flag, e.g.
dtool -Nmy_group -cAveD99 /tmp
 

 ==END==

>> top