Enabling Verbose Logging to Troubleshoot Application Launches

Introduction

Secure Global Desktop relies on a series of expect scripts to help automate the launch process for hosted applications. With each release of the product, every attempt has been to made to generalize these scripts sufficiently to allow execution in wildly varied environments, but problems do occasionally arise.

Launch failures may be triggered by any number of independent configuration problems; examples include:bad execution paths, connection protocols, or display methodologies. Fortunately, each of these situations are readily identifiable by systematically reviewing the captured logs of a failed launch attempt.

Step-by-Step Instructions

In the process of investigating most launch problems, it helps to review the dialog between the automated SGD scripts and the application server for anomalies in execution.

The following instructions outline the procedure to enable verbose logging of the launch process for UNIX / Linux applications.  Due to the simple connection process used by RDP applications, verbose logging is rarely useful for troubleshooting.

Note: SGD is installed by default within the /opt/tarantella directory. This fact is reflected in the path of most of the commands, and file locations referenced below. Deviations from this standard within installed environments will require that these paths are updated before execution in your environment.

SETUP

1. Before implementing any changes below, we recommend that the administrator create a backup copy of unix.exp script. By default, this file is found in the following directory:

/opt/tarantella/var/serverresources/expect/unix.exp

2. After creating an archived copy, edit the working script by updating the following lines as indicated and saving your changes.

# Uncomment to turn on the extra debug - lots of information so default is off
# startdebug

# Try to optimise
optimiselaunch

to:

# Uncomment to turn on the extra debug - lots of information so default is off
startdebug

# Try to optimise
# optimiselaunch


3. Document the log filters that are currently enabled within your environment by executing the following command:

# /opt/tarantella/bin/tarantella config list --tarantella-config-execpeconfig-logfilter


4. Enable verbose logging by updating your logfilter using the following command:

/opt/tarantella/bin/tarantella config edit --tarantella-config-execpeconfig-logfilter execpe/*/*

TEST

5.  If an intermittent failure launch failure is occurring, try to run the capture both a successful launch as well as an unsuccessful launch, as the differences in the recorded logs may help to isolate the error condition.  It is important to note, however, that the more succinct the dataset, the more useful the data.

6. At the conclusion of the test period, we will want to force the SGD processes to flush their buffers to disk, by archiving the logs.

# /opt/tarantella/bin/tarantella archive


7. The debug launch events should now be written to files named 'execpe*', and written to the /opt/tarantella/var/log/1 subdirectory.

RESTORATION

After resolving the issue, it is advised to return the SGD environment to its previous state. To do so:

8. Reset the logfilter to it's original setting, as documented within step #3. The example below demonstrates the syntax to reset this component to it's default parameter.

tarantella config edit --tarantella-config-execpeconfig-logfilter \
"execpe/*/*error" "pem/*/*error" "launchhelper/*/*error"

9. Restore the unix.exp script to it's original form using the archived copy created in step #1.

Additional Resources

Login Script Error Messages - SGD 4.40 Admin Guide 

Login Scripts Supplied with SGD - SGD 4.40 Admin Guide 

Login Script TCL Commands and Procedures - SGD 4.40 Admin Guide 

Login Script Variables - SGD 4.40 Admin Guide 

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Sun Microsystems community and they might not be employed or in any way formally affiliated with Sun Microsystems. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Sun nor any other party necessarily agrees with them.

Copyright 1994-2009 Sun Microsystems, Inc.
Powered by Atlassian Confluence
Sun Guidelines on Public Discourse Privacy Policy Terms of Use Trademarks Site Map Employment Investor Relations Contact