7.4. Monitoring and Logging

This section describes the SGD datastore, how to monitor user activity, and how to configure logging.

This section includes the following topics:

7.4.1. The SGD Datastore

The SGD servers in an array share information. Each SGD server knows:

  • What applications are configured and the applications servers on which they run

  • Which users have access to applications

  • Who is logged in to SGD

  • Which applications users are running

The collection of information is known as the datastore.

Information about users, applications, application servers, and webtops is stored on disk in the local repository. Information about user and application sessions is stored in memory.

The datastore is organized into namespaces which are displayed and used on the command line and log files. The general structure is .../namespace/name-within-namespace. The ... indicates the root of the datastore. The namespace indicates the source of the information, such as DNS. After the namespace, names are written using whichever naming scheme is appropriate to the namespace. Names are written like file system paths (slash-separated and top-down).

The following are some commonly used namespaces.

Namespace

Description

Example

Local

SGD objects in the local repository

.../_ens/o=Example/ou=Marketing/cn=Cust-o-Dat

LDAP

Objects in an LDAP directory

.../_service/sco/tta/ldapcache/cn=Cust-o-Dat,ou=Marketing,o=Example

DNS

Machines on the network

.../_dns/verona.example.com

7.4.2. User Sessions and Application Sessions

This section describes the differences between user sessions and application sessions in SGD. Using the Administration Console and the command line to monitor and control user and application sessions is also covered.

This section includes the following topics:

7.4.2.1. User Sessions

A user session begins when a user logs in to SGD and ends when a user logs out of SGD. User sessions are hosted by the SGD server the user logs in to. The user name and password they type determine the type of user they are. See Chapter 2, User Authentication for more details about user authentication.

If a user logs in and they already have a user session, the user session is transferred to the new SGD server and the old session ends. This is sometimes called session moving, or session grabbing.

User sessions can be standard sessions or secure sessions. Secure sessions are only available when SGD security services are enabled. See Section 1.5, “Secure Connections to SGD Servers” for more details.

In the Administration Console, you can list user sessions as follows:

  • The Sessions tab, in Navigation View, shows all the user sessions that are running on all SGD servers in the array

  • The User Sessions tab for an SGD server shows all the user sessions that are hosted by that SGD server

  • The User Sessions tab for a user profile shows all the user sessions associated with the user profile

The Sessions tab and User Sessions tab enable you to select and end user sessions. The User Sessions tab enables you to view further details about the user session. For example, the information that the SGD Client detects about the client device.

On the command line, you use the tarantella webtopsession command to list and end user sessions.

7.4.2.1.1. Idle User Session Timeout

You can configure an idle timeout period for inactive user sessions. User sessions are ended automatically if there has been no activity on the AIP connection between the SGD Client and the SGD server for the specified period. The timeout is disabled by default for an SGD array.

Activity on the following devices has no effect on the idle timeout period:

  • Serial ports

  • Smart cards

  • Audio

To specify the idle timeout attribute, go to the Global Settings → Communication tab of the Administration Console and type a value in the User Session Idle Timeout field.

Alternatively, use the following command:

$ tarantella config edit --webtop-session-idle-timeout secs

Replace secs with the timeout value, measured in seconds. A setting of 0 turns off the user session idle timeout feature. This is the default setting.

Caution

Do not configure an idle timeout that is less than 300 seconds (five minutes).

You must restart every SGD server in the array for changes to this attribute to take effect.

7.4.2.2. Application Sessions

An application session begins when a user starts an application and ends when the application exits. Each application session corresponds to an application currently running through SGD.

An application session can be hosted by any SGD server in the array. This might not be the same SGD server that the user logged in to, see Section 7.1, “Arrays”.

Each application session has a corresponding Protocol Engine process. The Protocol Engine handles the communication between the client device and the application server. The Protocol Engine also converts the display protocol used by the application to the AIP, which is understood by the SGD Client running on the client device.

You can use application session load balancing to spread the load of the Protocol Engines among the SGD servers in the array. See Section 7.2.2, “Application Session Load Balancing” for more details.

Some applications can be configured to keep running, even when they are not displayed. These are called resumable applications.

Resumable applications are useful for the following reasons:

  • Applications that take a long time to start can be left running, even after users have logged out of SGD

  • Mobile users can leave applications running while they travel

  • Users can easily recover from browser or other crashes

Each application object has an Application Resumability attribute that determines the application's resumability behavior. Applications can have one of the following Application Resumability settings.

Setting

Description

Never

The application exits when the user logs out of SGD. You cannot suspend or resume applications that are non-resumable.

During the User Session

The application continues to run until the user logs out of SGD. While they are logged in, the user can suspend and resume these applications.

General

The application continues to run even after the user has logged out of SGD. When the user logs in again, they can click the Resume button to display the running application again.

If an application is resumable, it is resumable for a period of time, specified by a timeout. If the SGD Client exits unexpectedly or the connection to the SGD server is lost, the timeout period is the configured timeout plus 20 minutes.

The 20 minute connection timeout enables the SGD server to reestablish the connection with the SGD Client. After this time period, the user session ends. To change the value of the connection timeout, use the following command:

# tarantella config edit --tarantella-config-array-restartconnectiontimeout mins

where mins is the connection timeout period, in minutes.

Table 7.1, “Application Resumability Scenarios” describes application resumability behavior for some typical scenarios.

Table 7.1. Application Resumability Scenarios

Scenario

Description

User logs out from SGD

The user session ends immediately.

The application session behavior then depends on the Application Resumability setting for the application object as follows:

  • Never: The application session ends immediately.

  • During the User Session: The application session ends immediately.

  • Always: The application session ends after the time period specified by the Application Resumability: Timeout attribute for the application object.

    If the user logs in again before this time period passes, the application session is resumed.

Connection to the SGD server is lost

SGD detects that the connection between the SGD Client and the SGD server is lost, and a timeout period of 20 minutes begins.

If the connection is restored within 20 minutes, the application session can be resumed.

After 20 minutes have expired, the user session ends. The application session behavior then depends on the Application Resumability setting for the application object as follows:

  • Never: The application session ends immediately.

  • During the User Session: The application session ends after the time period specified by the Application Resumability: Timeout attribute for the application object.

    If the user logs in again before this time period passes, the application session can be resumed.

  • Always: The application session ends after the time period specified by the Application Resumability: Timeout attribute for the application object.

    If the user logs in again before this time period passes, the application session can be resumed.

SGD Client exits unexpectedly

SGD detects that the SGD Client has exited unexpectedly, and a timeout period of 20 minutes begins.

If the application has an Application Resumability setting of Never, the application session is ended immediately. Otherwise, the application session can be resumed within the 20 minutes timeout period.

After 20 minutes have expired, the user session ends. The application session behavior then depends on the Application Resumability setting for the application object as follows:

  • During the User Session: The application session ends after the time period specified by the Application Resumability: Timeout attribute for the application object.

    If the user logs in again before this time period passes, the application session is resumed.

  • Always: The application session ends after the time period specified by the Application Resumability: Timeout attribute for the application object.

    If the user logs in again before this time period passes, the application session is resumed.


In the Administration Console you can list application sessions as follows:

  • The Application Sessions tab for an SGD server shows all the application sessions that are hosted by that server

  • The Application Sessions tab for a user profile shows all the application sessions associated with the user profile

  • The Application Sessions tab for an application server shows all the applications that are running on that application server

The Applications Sessions tab enables you to view details about each application session. You can also end and shadow application sessions. Shadowing a session enables you and the user see and interact with the application at the same time.

See Section 4.9.9, “Using Shadowing to Troubleshoot a User's Problem” for more details about shadowing application sessions.

Note

You can only shadow Windows applications and X applications. The application sessions must not be suspended.

On the command line, you use the tarantella emulatorsession command to list and end user sessions.

7.4.2.3. Anonymous Users and Shared Users

There are two special cases, as follows:

To be able to distinguish between these users, SGD assigns shared users and anonymous users a temporary user identity when they log in. This has the following effects:

  • User sessions do not transfer if the user logs in to SGD more than once

  • Application sessions end as soon as the user session ends, regardless of the application's Application Resumability setting

  • If the user does not log out, server resources are consumed

7.4.3. Using Log Filters to Troubleshoot Problems With an SGD Server

When you first install SGD, the default log filters log all errors on the SGD server. If you want to obtain more detailed information, for example to troubleshoot a problem, you can set additional log filters.

You can set additional log filters in the following ways:

  • Type the filter in the Log Filter field on the Global Settings → Monitoring tab in the Administration Console. Each filter must be separated by a Return key press.

  • Use the following command:

    $ tarantella config edit --array-logfilter filter...
    

    Separate multiple filter entries with a space and enclose in double quotation marks (" ").

Each log filter has the form:

component/subcomponent/severity:destination

The options for each part of the filter, and how you view the log output, are described in the following sections.

Note

Log filters can create large amounts of data. It is good practice to set as specific a filter as possible and then remove the filter when you have finished with it.

7.4.3.1. Selecting a Component and Subcomponent

Selecting a component and subcomponent enables you to choose the area of information you want to log from the SGD server.

The following table shows the available component/subcomponent combinations and an explanation of the kind of information produced.

Component and Subcomponent

Information Provided

audit/glue

Audit of changes made to the SGD server configuration, or to your local repository configuration, and who made the changes.

For example, you can use this to find out who made changes to a user profile object.

audit/session

Starting and stopping user sessions and application sessions.

For example, you can use this to find out how long a user had a running application session.

cdm/audit

Authorization of SGD user for client drive mapping (CDM) purposes.

For example, you can use this to find out whether a user's credentials are causing CDM to fail.

cdm/server

Information about CDM services.

For example, you can use this to find out whether a client connection error is causing CDM to fail.

common/config

How SGD server configuration is stored and copied across the array.

For example, you can use this to find out why a global setting configuration change is not being applied to an SGD server.

metrics/glue

Memory and timings.

For example, you can use this to find out how long it took to run an SGD command.

metrics/soap

The SOAP component of Tomcat's SOAP proxy.

For example, you can use this to trace how long it took a SOAP request to finish.

server/billing

SGD billing services.

For example, you can use this to find out why billing data is being lost.

server/common

General SGD information.

For example, you can use this to troubleshoot DNS errors.

server/config

Changes to SGD server configuration.

For example, you can use this to log changes to SGD server configuration or to find out if the configuration has become corrupt.

server/csh

The SGD client session handler.

For example, you can use this to find out why a user can not restart an application session.

server/deviceservice

Mapping of users to accessible device data.

For example, you can use this to find out why a user can not access client drives.

server/directoryservices

Connections to Active Directory or LDAP.

For example, you can use this to find out why an Active Directory or LDAP user cannot log in.

server/diskds

Information about the local repository.

For example, you can use this to get information about corrupt objects or inconsistencies in the local repository.

server/failover

Information about array failover.

For example, you can use this to troubleshoot problems with an SGD array where the primary server is unavailable.

server/glue

The protocol used for communication between SGD servers.

For example, you can use this to find out why SGD servers cannot communicate.

server/install

Installation and upgrades.

For example, you can use this to investigate problems with an installation.

server/kerberos

Windows Kerberos authentication.

For example, you can use this to find out why an Active Directory user cannot log in.

server/launch

Starting or resuming applications.

For example, you can use this to find out why a user cannot start an application.

server/loadbalancing

User session and application load balancing.

For example, you can use this to find out why an SGD server is not selected to host application sessions.

server/logging

Logging.

For example, you can use this to find out why log messages are not being written to a file.

server/login

Log in to SGD.

For example, you can use this to find out which authentication mechanism authenticated a user and the user profile used.

server/mupp

The SGD MUltiplePlexing Protocol (MUPP) protocol.

Only use this filter if Support ask you to.

server/printing

SGD printing services.

For example, you can use this to find out why print jobs are failing.

server/replication

Copying data between SGD servers in an array.

For example, you can use this to find out why data has not been copied between array members.

server/securid

Connections to SecurID RSA Authentication Manager.

For example, you can use this to find out why SecurID authentication is not working.

server/security

Secure SSL-based connections.

For example, you can use this to find out why the SSL Daemon is not running.

server/server

The SGD server component.

For example, you can use this to troubleshoot SGD server failures, such as Java™ technology runtime exceptions which are not logged elsewhere.

server/services

Internal SGD server services.

For example, you can use this to find out why a service is failing.

server/session

User sessions.

For example, you can use this to find out why a session failed to suspend.

server/soap

SOAP bean interface.

For example, you can use this to diagnose problems with the SOAP beans.

server/soapcommands

SOAP requests.

For example, you can use this to log the SOAP requests received.

server/tier3loadbalancing

Application server load balancing.

For example, you can use this to find out why an application server is not being selected to run an application.

server/tscal

Windows Remote Desktop Services Client Access Licenses (CALs) for non-Windows clients.

For example, you can use this to find out why a non-Windows client does not have a CAL.

server/webtop

Webtop content, if you are using Directory Services Integration.

For example, you can use this to find out why an application is not appearing on a user's webtop.

7.4.3.2. Selecting the Severity

You can select one of the following levels of severity for each log filter.

Severity

Description

fatalerror

Logs information on fatal errors. Fatal errors stop the SGD server from running. When you first install SGD, all fatal errors are logged by default.

error

Log information on any errors that occur. When you first install SGD, all errors are logged by default.

warningerror

Log information on any warnings that occur, for example if system resources are running low. When you first install SGD, all warnings are logged by default.

info

Informational logging. Useful for problem solving and identifying bugs.

moreinfo

Verbose informational logging.

auditinfo

Logs selected events for auditing purposes, for example changes to SGD server configuration. For details see, Section 7.4.4, “Using Log Filters for Auditing”.

The fatalerror severity level produces the least amount of information. The moreinfo severity level produces the most information.

Selecting a severity level is not cumulative. For example, selecting info does not mean you also see warningerror or fatalerror log messages.

To log more than one level of severity, use a wild card.

7.4.3.2.1. Using Wildcards

You can use a wildcard (*) to match multiple components, subcomponents, and severities.

For example, to log all warning, error, and fatal error messages for printing, you can use a server/printing/*error log filter.

Note

If you use a wildcard on the command line, you must enclose the filter in straight quotation marks, to stop your shell from expanding them.

7.4.3.3. Selecting a Destination

When selecting a destination for the logs, you can specify that the output goes to one of the following destinations:

  • A log file

  • A log handler

These destinations are described in the following sections.

7.4.3.3.1. Using Log Files

If you direct the output to a log file, you can output to the following types of file:

  • filename.log

    SGD formats this log output so that it is easy to read.

    This format is required by the tarantella query errlog command. This command only searches log files that have names that end error.log.

  • filename.jsl

    SGD formats this log output for automated parsing and searching.

    This format is required by the tarantella query audit command.

The file extension of the destination file controls the format of the file.

You can also create a separate log file for each process ID, by including the %%PID%% placeholder in the file name.

The log files are output in the /opt/tarantella/var/log directory. You cannot change the location of the log files, but you can use a symbolic link to redirect the logs to a different location. Alternatively, you can use the syslog log handler described in Section 7.4.3.3.2, “Using Log Handlers”.

7.4.3.3.2. Using Log Handlers

A log handler is a JavaBeans component used as the destination for the log messages. When specifying a log handler, you must use its full name. SGD provides the following log handlers:

  • ConsoleSink. The ConsoleSink log handler writes log messages in a easy-to-read format to standard error. This log handler is enabled by default and logs all fatal errors.

    The full name of this log handler is:

    .../_beans/com.sco.tta.server.log.ConsoleSink
  • SyslogSink. The SyslogSink log handler writes log messages to the UNIX or Linux platform syslog facility.

    The full name of this log handler is:

    .../_beans/com.sco.tta.server.log.SyslogSink

7.4.3.4. Examples of Using Log Filters

The following are some examples of commonly used log filters:

  • To debug user logins:

    server/login/*:login%%PID%%.log
    server/login/*:login%%PID%%.jsl
  • To troubleshoot CDM:

    cdm/*/*:cdm%%PID%%.log
    cdm/*/*:cdm%%PID%%.jsl
    server/deviceservice/*:cdm%%PID%%.log
    server/deviceservice/*:cdm%%PID%%.jsl
  • To troubleshoot printing problems:

    server/printing/*:print%%PID%%.log
    server/printing/*:print%%PID%%.jsl
  • To get timing measurements for server performance:

    metrics/*/*info:metrics.log
    metrics/*/*info:metrics.jsl
  • To send all warnings, errors, and fatal errors to syslog:

    */*/*error:.../_beans/com.sco.tta.server.log.SyslogSink

7.4.3.5. Viewing Log Output

To view the log output, you can do either of the following:

  • Open the .log files in a viewer or text editor

  • Use the tarantella query command

If you use the tarantella query command, use the following command options:

  • tarantella query errlog – To see only the errors and fatal errors for specific SGD server components

  • tarantella query audit – Searches the logs for any messages relating to a person, an application, or an application server

Note

You can only use these commands to view the log output until the logs are archived. You configure archiving when you install SGD, but you can change the settings at any time by running the tarantella setup command.

7.4.4. Using Log Filters for Auditing

SGD enables you to set log filters to provide an audit of the following system events:

  • Starting and stopping an SGD server

  • Starting and stopping SGD security services

  • Changes to object configuration in the local repository

  • Changes to global and SGD server configuration

  • Unsuccessful attempts to log in to an SGD server

  • Logging in and out of SGD

  • Starting and stopping an application session

To audit these events, you must set a */*/*auditinfo log filter.

You can use any of the standard destinations as a destination for the output, but you must direct the output to a .jsl file if you want to view the audit information from the command line.

See Section 7.4.3, “Using Log Filters to Troubleshoot Problems With an SGD Server” for more information about setting log filters.

Note

Log output is only created while an SGD server is actually running. If an SGD server is stopped, only the UNIX system root user can perform any of the auditable events.

For each of the events, the log filter records following:

  • The date and time of the event

  • The type of event

  • The result of the event, whether it was successful or it failed

  • The identity of the user responsible for the event

  • Any other relevant information about the event, for example what was changed and to what value

7.4.4.1. Viewing Audit Log Information

You can use any of the standard methods for viewing the log output. However, the following command is the most useful:

# tarantella query audit --format text|csv|xml --filter "filter"

If you select the text format, SGD formats the log output so that it is easy to read on screen, but it does not show every detail logged. Using the csv format shows every detail logged, but it is only suitable for outputting to a file.

The "filter" is an RFC2254-compliant LDAP search filter. The command searches the log fields in the log files for matching entries to display. For auditing purposes, the most useful log fields are shown in the following table.

Log Field

Description

log-category

For auditing purposes, the log-category is always *auditinfo, but this can be any of the standard log filter component/subcomponent/severity settings.

log-date

The system date and time when the event took place.

The format is yyyy/MM/dd HH:mm:ss.SSS.

log-event

The name of the event.

log-ip-address

The IP address of a client or server associated with an event.

log-keyword

The keyword identifier for the auditable event.

log-localhost

The peer DNS name of the SGD server where the event took place.

log-pid

The process ID of the event.

log-security-type

The type of security used on a connection, std or ssl.

log-systime

The system Coordinated Universal Time (UTC) time, in milliseconds, when the event took place.

log-tfn-name

The full name of an object associated with an event.

For example, starting an application session might record the name of the user, the application, and the application server.

Note

A complete list of all the log fields is available in the /opt/tarantella/var/serverresources/schema/log.at.conf schema file.

The following table below shows all the log-keywords, and their corresponding log-events, together with a description of the event.

Log-Keyword

Log-Event

Description

createFailure

createFailure

A user tried to create an object in the local repository but failed.

createSuccess

createSuccess

A user created an object in the local repository.

deleteFailure

deleteFailure

A user tried to delete an object in the local repository but failed.

deleteSuccess

deleteSuccess

A user deleted an object in the local repository.

loginFailure

loginResultReconnect

The SGD server requested the client to reconnect on a different port.

loginFailure

loginResultFailed

None of the enabled authentication mechanisms authenticated the user.

loginFailure

loginResultRejected

User was denied a login by a login filter. For example, this might be because logins are currently not enabled for that particular server, or because the user is currently not allowed to log in.

loginFailure

loginResultDisabled

The SGD server is not currently accepting connections.

loginFailure

loginResultNoAmbig

An ambiguous login failed because the SGD server does not support ambiguous logins.

loginFailure

loginResultAmbiguous

An ambiguous login failed because the user did give enough disambiguation information.

loginFailure

loginResultAnonymous

An anonymous login failed because the SGD server does not support anonymous logins.

loginFailure

loginResultNoSecurity

Login failed because the user requires a secure connection, but the connection was made to the standard port.

loginFailure

loginResultUnresolveable

Login failed because the SGD server was unable to resolve which user had logged in.

loginFailure

loginResultUnknown

Login failed because the SGD server was unable to process an unexpected login result.

loginSuccess

webtopSessionStartedDetails

Started a user session for a user.

logout

webtopSessionEndedDetails

Stopped a user session for a user.

modifyFailure

modifyFailure

A user tried to change an object in the local repository, to change global settings, or to change the configuration of an SGD server but failed.

modifySuccess

modifySuccess

A user changed an object in the local repository, changed global settings, or changed the configuration of an SGD server.

renameFailure

renameFailure

A user tried to rename an object in the local repository but failed.

renameSuccess

renameSuccess

A user renamed an object in the local repository.

serverStart

serverStart

The SGD server was started.

serverStop

serverStop

The SGD server was stopped.

sessionEnded

sessionEndedDetails

Stopped an application session for a user.

sessionStarted

sessionStartedDetails

Started application session for a user.

sslStart

securitySSLStart

Started SGD security (SSL) services.

sslStop

securitySSLStop

Stopped SGD security (SSL) services.

7.4.4.2. Examples of Using Log Filters for Auditing

To search for failed log in attempts, use the following filter:

--filter "(&(log-category=*auditinfo)(log-keyword=loginFailure))"

To search for changes to made to the SGD server configuration by the Administrator Bill Orange, use the following filter:

 --filter "(&(log-category=*auditinfo)(log-keyword=modifySuccess)
 (log-tfn-name=.../ens/o=Example/ou=IT/cn=Bill Orange))"

7.4.5. Using Log Filters to Troubleshoot Problems With Protocol Engines

When you first install SGD, the default log filters record all errors for protocol engines (PEs). To obtain more information about PE activity, you can set additional PE log filters.

PE log filters can be set for individual PEs, and for the Protocol Engine Manager (PE Manager) process. You configure a PE log filter by setting one of the attributes shown in the following table.

PE Filter Attribute

Protocol Engine

--tarantella-config-auxserver-logfilter

PE Manager

--tarantella-config-execpeconfig-logfilter

Execution Protocol Engine

--tarantella-config-xpeconfig-logfilter

X Protocol Engine

--tarantella-config-tpeconfig-logfilter

Character Protocol Engine

--tarantella-config-ppeconfig-logfilter

Print Protocol Engine

--tarantella-config-cpeconfig-logfilter

Channel Protocol Engine

You can only set a PE log filter from the command line. Use the following command:

$ tarantella config edit --PE-filter-attribute filter...

where PE-filter-attribute defines the PE filter attribute you want to configure, and filter defines the log filter. For multiple log filter definitions, use straight quotation marks to separate each filter parameter.

Each log filter has the form:

component/subcomponent/severity

The following table shows the available component names for PE logging.

Protocol Engine

Component

PE Manager

pem

proxy

Execution Protocol Engine

execpe

launchhelper

X Protocol Engine

xpe

pem

Character Protocol Engine

tpe

pem

Print Protocol Engine

ppe

pem

Channel Protocol Engine

cpe

pem

For subcomponent, type * to include information on all subcomponents.

You can select the following levels of severity:

  • * – Includes all error and warning messages.

  • *info – Includes info, moreinfo, and auditinfo messages.

  • *error – Includes error, fatalerror, and warningerror messages. This is the default severity.

Changes to the Execution, X, Character, Print, and Channel PE log filters take effect when a new PE is started.

Changes to the PE Manager log filters require an SGD server restart.

Note

Log filters can create large amounts of data. It is good practice to set as specific a filter as possible and then remove the filter after you have finished with it. See Section 7.4.5.4, “Resetting a PE Log Filter” for details of how to do this.

7.4.5.1. Examples of Using PE Log Filters

The following are some examples of how to use a PE log filter.

  • To troubleshoot CDM for X and Windows applications:

    --tarantella-config-xpeconfig-logfilter "xpe/cdm/*"
  • To troubleshoot problems with X and Windows applications:

    --tarantella-config-xpeconfig-logfilter "xpe/*/*" "pem/*/*"
  • To troubleshoot application launches, you must first enable debugging in the SGD login scripts, as shown in Section 4.9.1, “An Application Does Not Start”. Then, configure the Execution Protocol Engine log filter as follows:

    --tarantella-config-execpeconfig-logfilter "execpe/*/*"
Note

For the execpe, xpe, tpe, ppe, and cpe log filters, using the pem/* filter shows relevant PE Manager messages for the Protocol Engine.

7.4.5.2. PE Log File Destinations

PE log files have the file name extension .log. SGD formats this type of log output so that it is easy to read.

PE log file names include the name of the PE component and the process ID. For example, messages for a PE Manager running with process ID 4512 are stored to a file named pemanager4512.log.

Error messages with a severity of error, fatalerror, or warningerror are stored to a PE log file with a name that ends error.log. For example, error messages for a Character Protocol Engine running with process ID 2256 are stored to a file named cpe2256_error.log. Files such as this are used by the tarantella query errlog command, which only searches log files that have names that end error.log.

PE log filter output is directed automatically to log files in the /opt/tarantella/var/log directory on the SGD host. You cannot change the location of the log files, but you can use a symbolic link to redirect the logs to a different location.

7.4.5.3. Viewing PE Log Output

To view the PE logs, do either of the following:

  • Open the .log files in a viewer or text editor.

    On each SGD server in the array, the .log files contain messages for PEs running on that specific SGD server.

  • Use the tarantella query errorlog command to show error messages for PEs.

    This command can be used to search all PE error logs in the array.

    For example, to display X Protocol Engine error messages for all SGD servers in the array, use the following command:

    $ tarantella query errlog xpe

    For example, to display X Protocol Engine error messages for the SGD server boston.example.com, use the following command:

    $ tarantella query errlog xpe --server boston.example.com
Note

You can only use these commands to view the log output until the logs are archived. You configure archiving when you install SGD, but you can change the settings at any time by running the tarantella setup command.

7.4.5.4. Resetting a PE Log Filter

As log filters can create large amounts of data, it is good practice to reset the filter to its default configuration after you have finished with it.

The default PE log filter configuration sets a severity level of *error for all subcomponents of the PE component. The following table shows the default configuration for each log filter.

Protocol Engine

Default Log Filter Configuration

PE Manager

pem/*/*error

proxy/*/*error

Execution Protocol Engine

execpe/*/*error

pem/*/*error

launchhelper/*/*error

X Protocol Engine

xpe/*/*error

pem/*/*error

Character Protocol Engine

tpe/*/*error

pem/*/*error

Print Protocol Engine

ppe/*/*error

pem/*/*error

Channel Protocol Engine

cpe/*/*error

pem/*/*error

For example, to reset an X Protocol Engine log filter use the following command:

$ tarantella config edit \
--tarantella-config-xpeconfig-logfilter "xpe/*/*error" "pem/*/*error"

7.4.6. SGD Web Server Logging

SGD web server messages are recorded in the following logs:

  • Tomcat JSP technology container logs

  • Apache web server logs

7.4.6.1. Tomcat JSP Technology Container Logs

Log messages for the Tomcat JSP technology container component of the SGD web server are written to the following files in the /opt/tarantella/webserver/tomcat/tomcat-version/logs directory on the SGD host:

  • catalina.out – This log file is rotated when full, or when the Tomcat JSP technology container is restarted, and the contents are appended to catalina.out.sav.

  • localhost_log.date.txt – This is a daily log file, where date is the date that messages were recorded.

You can read these log files with a text editor.

The Tomcat JSP technology container log files can be used to diagnose problems with the following:

  • Starting and stopping the Tomcat JSP technology container

  • Starting the AJP 1.3 Connector

  • Loading the SGD webtop web application

  • Webtop JSP software exception errors

Logging properties for the Tomcat JSP technology container are configured in the /opt/tarantella/webserver/tomcat/tomcat-version/conf/logging.properties file. See the Tomcat documentation for details of how to configure logging for a Tomcat JSP technology container.

7.4.6.2. Apache Web Server Logs

Log messages for the Apache web server component of the SGD web server are written to the following files in the /opt/tarantella/webserver/apache/apache-version/logs directory on the SGD host:

  • errors_log – Logs error messages for the Apache web server

  • access_log – Logs all access requests processed by the Apache web server

You can read these log files with a text editor.

The Apache web server log files can be used to diagnose problems with the following:

  • Starting and stopping the Apache web server

  • Client requests for SGD webtop pages

  • Web authentication

See the Apache documentation for more details about these log files.

7.4.7. SGD Client Logging

By default, log messages for the SGD Client are stored to the following locations on the client device:

  • Microsoft Windows client devices. A file called tcc.txt in a user-specific writeable directory.

    • On Microsoft Windows XP platforms, for example:

      C:\Documents and Settings\username\Local Settings\Application Data\Sun\SSGD

    • On Microsoft Windows 7 platforms, for example:

      C:\Users\username\AppData\Local\Temp\Sun\SSGD

    The actual location depends on the user's privileges, the operating system, and the version of the Java Plug-in software being used.

    Users can view the contents of the tcc.txt file with a text editor.

  • UNIX, Linux, or Mac OS X platform client devices. The system log location for the client device.

    • On Oracle Linux platforms, for example:

      /var/log/messages

    • On Oracle Solaris platforms, for example:

      /var/adm/messages

    • On Mac OS X platforms, for example:

      /var/log/system.log

    Note

    The system log on the user's client device might be in a different location from those listed. On some client platforms, users might need privileges to view the system log.

Users can override the default log directory by using the -logdir command line argument when the SGD Client is started manually. In this case, a tcc.txt file is created in the specified directory location.

The default log directory is used if the -logdir argument is not specified when starting the SGD Client manually.

The SGD Client log file can be used to diagnose problems with the following:

  • Starting the SGD Client and the SGD Client Helper

  • Loading the SGD webtop page

  • Client devices, such as CDM, printing, and smart card services

  • Connections between the SGD Client and the SGD server

Users configure the logging level for SGD Client messages by changing the Logging Level setting in their client profile. The available logging levels, arranged in increasing level of verbosity, are:

  • No Logging – Turns off SGD Client logging.

  • Errors only – Records error messages. This is the default setting.

  • Errors and Warnings only – Records error messages and warning messages.

  • All – Records all messages, including error messages, warning messages, and information messages.

Client device information is shown on the Info → Detailed Diagnostics page of the user's webtop.

Administrators can use the Administration Console to view client device information for a user session. Select the user session in the User Session List table and click the View Details button to show more details.