Secure Global Desktop Administration Guide > Users and authentication > Increasing launch timeouts

Increasing launch timeouts

If you're running applications on a particularly sluggish application server, Secure Global Desktop may fail to start applications, reporting an ErrApplicationServerTimeout error.

You can fix this by increasing the launch timeouts in the vars.exp login script.

For a slow machine, we recommend that timeouts(loggedin) is increased. If the launch fails with ErrApplicationServerTimeout, one of the clienttimers is too short. If the launch is particularly slow, it may be better to increase all the clienttimers.

Note Changing the launch timeouts will slow down application start times, so only do this if you're experiencing problems, and tune the timeouts to the capabilities of the application server.

Note With the exception of the Execution Protocol Engine timeout, none of the timers discussed here is used when launching a Microsoft Windows application.

Expect timeouts

If an expect timeout expires, the script will attempt to guess the prompt, then continue with the launch.

timeouts(prelogin)

The time allowed for each expect command to match a required string during the login phase.

For example, after the connection is made to the application server, the script has prelogin seconds to match the login prompt before it times out. Every successful match resets the timer. During a login, the prelogin timer will usually be reset for the login, password and shell prompts.

Increasing the prelogin timer will increase the time allowed for each phase of the login. It should be large enough so that the longest phase can be completed.

If the timeout expires, the script assumes that it is logged in and has failed to match the shell prompt and sends "echo SYNC" to the application server to guess the promptstring. If the user was not logged in when the timer fired, the launch will fail. Otherwise, the shell prompt will be set to whatever the application server sent immediately after the "echo SYNC" and the launch continues.

Note If you can see "echo SYNC" and the shell prompt ends in the normal way with $ % # or >, the prelogin timer is too short.

timeouts(loggedin)

The time allowed for each expect command to match a required string once the user is logged in.

If the timeout expires, the script moves onto the next command, which may cause commands to be sent before the prompt has returned. The most common occurrence of this timeout is if the script incorrectly sets the shell prompt. This causes each command to wait loggedin seconds before moving to the next command and can trigger one of the clienttimers.

clienttimers

clienttimers are set using the clienttimer command. If a clienttimer expires, the launch is aborted with a fatal ErrApplicationServerTimeout error.

timers(login)

The total time for the complete login phase, from making the connection to receiving the first shell prompt.

The login timer must be large enough to cover all of the login phases. Each individual phase (login prompt, password prompt, shell prompt) may last up to prelogin seconds, so login should always be greater then prelogin.

Note If you increase the prelogin timer, you should increase the login timer as well so that the difference between them is never less than 10.

timers(env)

The total time from receiving the first shell prompt until all of the application server environment variables have been exported.

timers(runmain)

The total time from setting the last environment variable to launching the main application.

timers(build)

The total time taken to build the command line to be executed. This timer is only used when launching Merge applications.

timers(total)

The total number of clienttimers. You should only change this setting if you add or remove a clienttimer.

Other timeouts

The procs.exp login script includes a 3-second timeout when issuing commands (in proc wait_for_prompt).

A timeout of 3 minutes is hard-coded into the Execution Protocol Engine. This is started when the launch request is received and removed when the launch has successfully completed. If it expires, the launch is aborted.

Copyright © 1997-2005 Sun Microsystems, Inc. All rights reserved.