ここでは、アプリケーションで発生する可能性のあるいくつかの一般的な問題と、それらの解決方法について説明します。
アプリケーションの起動および終了時の問題をトラブルシューティングするには、次を参照してください。
アプリケーションの使用時の問題をトラブルシューティングするには、次を参照してください。
動的起動に使用されるブローカに関する問題をトラブルシューティングするには、次を参照してください。
ユーザーがリンクをクリックしてもアプリケーションが起動しない場合は、まずアプリケーションオブジェクトの設定を確認します。「アプリケーションオブジェクトの設定の確認」を参照してください。
それでも問題を解決できない場合は、起動の詳細またはログファイルを調べて、起動のエラーメッセージが記録されていないかどうかを確認します。「起動の詳細およびエラーログの確認」を参照してください。
ユーザーが SGD にログインできない場合や、アプリケーションを起動できない場合は、次のコマンドを実行することによって SGD サーバーのウォームリスタートを実行してください。
# tarantella restart sgd --warm
Administration Console で、アプリケーションオブジェクトの設定を確認します。
最初に、アプリケーションオブジェクトの「ホストしているアプリケーションサーバー」タブを確認します。アプリケーションを実行するには、少なくとも 1 つのアプリケーションサーバーを指定する必要があります。一覧表示されているアプリケーションサーバーが使用可能であることを確認します。
次に、アプリケーションオブジェクトの「起動」タブを確認します。次の表に示されている属性を確認します。
属性 | 確認項目 |
---|---|
アプリケーションコマンド | コマンドには、アプリケーションの実行可能ファイルのフルパス名が含まれていますか。 Windows アプリケーションオブジェクトの場合は、コマンドに含まれているファイル名拡張子も正しいですか。 そのパス名は、Windows ショートカットを指していますか。Windows ショートカットを指している場合は、アプリケーション自体のフルパス名に変更してください。 アプリケーションは、「ホストしているアプリケーションサーバー」タブに表示されているすべてのアプリケーションサーバー上で同じ場所にインストールされていますか。 |
コマンドの引数 | コマンド引数は正しいですか。 |
接続方法 | X アプリケーションオブジェクトと文字型アプリケーションオブジェクトの場合は、アプリケーションサーバーのタイプに適した「接続方法」が選択されていますか。 |
ログインスクリプト | ログインスクリプトが設定されていますか。 そのログインスクリプトは、アプリケーションのタイプに適していますか。 |
環境変数 | アプリケーションに必要なすべての環境変数が正しく設定されていますか。 |
アプリケーションオブジェクトが正しく設定されている場合は、アプリケーション自体が、すべてのアプリケーションサーバー上で実際に実行されることを確認します。
アプリケーションが起動に失敗すると、SGD は、「接続の進捗状況」ダイアログの詳細領域にエラーメッセージを表示します。このエラーメッセージは、ユーザーのホームディレクトリ内の SGD Client ログファイル (tcc.txt
) に出力されます。
エラーメッセージはまた、次のログファイルにも出力されます。
/opt/tarantella/var/log/execpe
PID
_error.log
このファイルには、実行プロトコルエンジンプロセスからのログ出力が含まれています。
/opt/tarantella/var/log/launchhelper
PID
_error.log
このファイルには、アプリケーションオブジェクトの接続方法が SSH である場合の追加のログ出力が含まれています。
エラーメッセージは、次の形式をしています。
ErrorMessage
Scriptprocess-id
exited with codeerror-code
and signalsignal
ErrorMessage
と error-code
は、問題のトラブルシューティングに使用できます。もっとも一般的なエラーメッセージを次に示します。
ErrApplicationServerTimeout
ErrApplicationServerLoginFailed
エラーメッセージとコードの完全なリスト、およびトラブルシューティング情報については、「ログインスクリプトのエラーメッセージ」を参照してください。
起動の詳細またはログファイルに Failed to find xauth
や Attempt to run xauth failed
などのエラーメッセージが表示される場合は、「X 認証が有効になっているときにアプリケーションの起動に失敗する」を参照してください。
依然として問題を解決できない場合は、ログファイルに出力される情報量を増やすことができます。これを行うには、実行プロトコルエンジンのログフィルタを修正し、さらに X アプリケーションと文字型アプリケーションの場合のみ、ログインスクリプトでのデバッグを有効にします。
実行プロトコルエンジンのログフィルタを修正するには、次のコマンドを使用します。
$ tarantella config edit \ --tarantella-config-execpeconfig-logfilter \ "execpe/*/*" "pem/*/*" "launchhelper/*/*"
ログインスクリプトでのデバッグを有効にするには、次のファイルを編集します。
アプリケーションオブジェクトに対して設定されたログインスクリプト。
startdebug
行の先頭からコメント記号 (#
) を削除します。
ログインスクリプトは通常、unix.exp
、securid.exp
、vms.exp
、unixclass.exp
、pupil.exp
のいずれかです。
procs.exp
stopdebug
行の先頭にコメント記号 (#
) を挿入します。
問題を解決したら、実行プロトコルエンジンのログフィルタをデフォルトの設定にリセットし、さらにログインスクリプトでのロギングを無効にする必要があります。ログフィルタをリセットするには、次のコマンドを使用します。
$ tarantella config edit \ --tarantella-config-execpeconfig-logfilter \ "execpe/*/*error" "pem/*/*error" "launchhelper/*/*error"
アプリケーションの起動時に ErrApplicationServerTimeout
エラーが発生した場合は、通常、ユーザーがログインする前にログインスクリプトがタイムアウトしたことを示しています。
この問題は、ログインスクリプトのタイムアウト時間を増やすことにより解決できます。使用可能なタイムアウト時間の詳細については、「ログインスクリプトのタイムアウト時間」を参照してください。
タイムアウト時間を変更する場合は、最初に Expect のタイムアウト時間を増やします。アプリケーションの起動が依然として失敗する場合は、いずれかのクライアントタイマーが短すぎる可能性があります。アプリケーションの起動が特に遅い場合は、すべてのクライアントタイマーを増やしてください。
ログインスクリプトのタイムアウト時間を増やすと、アプリケーションの起動に時間がかかります。タイムアウト時間を変更するのは問題が発生している場合だけにし、アプリケーションサーバーの能力に合わせてタイムアウト時間を調整してください。
実行プロトコルエンジンのタイムアウトを除くタイムアウトのいずれも、Microsoft Windows アプリケーションの実行時には適用されません。
アプリケーションの起動時に ErrApplicationServerLoginFailed
エラーが発生した場合は、ログインスクリプトがアプリケーションサーバーへのログインに失敗しました。
手動でアプリケーションサーバーにログインできるか確認してください。
ログインできる場合は、アプリケーションサーバーのシステムプロンプトがログインスクリプトによって認識されていることを確認してください。この障害の原因としてよくあるのは、一般的でないシステムプロンプトであり、これは次のことが原因で発生する可能性があります。
英語以外の言語のシステムプロンプト
今日のメッセージ (/etc/motd
) または発行メッセージ (/etc/issue
)
メニューを実行するように構成されている、ユーザーのログインプロファイル
デフォルトでは、SGD は、アプリケーションサーバー上で英語のシステムプロンプトをサポートしています。管理者は、ほかの言語のシステムプロンプトのサポートを追加できます。詳細は、「異なる言語のシステムプロンプトのサポートを追加する」を参照してください。
標準の SGD ログインスクリプトを使用している場合は、vars.exp
ログインスクリプトで定義されたシステムプロンプトを確認してください。
今日のメッセージまたはメニューが原因でログインスクリプトが失敗している場合は、この状況に対処するようにログインスクリプトを設定する必要があります。または、テクニカルサポートに問い合わせてください。
ログインスクリプトでタイムアウトが発生している可能性もあります。起動の詳細またはログファイルに echo SYNC
が表示されており、システムプロンプトが正常に $
、%
、#
、または >
で終了する場合は、vars.exp
ログインスクリプト内の timeouts(prelogin)
値を増やしてみてください。詳細は、「Expect のタイムアウト時間」を参照してください。
この問題は X アプリケーションで発生する可能性があります。この問題を解決するには、アプリケーションの起動に使用されるネットワーク接続を開いたままにします。
Administration Console で、アプリケーションオブジェクトの「起動」タブにある「起動接続をオープンしたまま保持」チェックボックスを選択します。
または、次のコマンドを実行します。
$ tarantella object edit --name obj
--keepopen true
デフォルトの SGD インストールでは、X 認証が有効になっています。X 認証に問題がある場合には、ユーザーはアプリケーションを起動できません。アプリケーションが X 認証のために起動に失敗した場合は、アプリケーションの起動の詳細およびログファイルに Failed to find xauth
または Attempt to run xauth failed
というメッセージが表示されます。
次のチェックリストを使用して、X 認証の何が原因でアプリケーションの起動に失敗しているのかを判断してください。それでも問題を解決できない場合は、「起動の詳細およびエラーログの確認」の説明に従ってログファイルを確認してください。
Questions
Questions and Answers
4.9.3.1: X 認証がアプリケーションサーバーにインストールされていますか。
SGD が X 認証を使用できるようにするには、すべてのアプリケーションサーバーに xauth をインストールする必要があります。
xauth がインストールされていない場合は、それをインストールするか、またはすべてのアプリケーションでの X 認証の使用を無効にする必要があります。X 認証を無効にするには、Administration Console の「グローバル設定」 → 「セキュリティー」タブで、「X ディスプレイの X 認証」チェックボックスの選択を解除します。
4.9.3.2: SGD が xauth バイナリを見つけることができますか。
アプリケーション起動ダイアログまたはログファイルに Failed to find xauth
というメッセージが表示されている場合は、SGD が xauth バイナリを見つけることができません。デフォルトでは、SGD は、次の場所で xauth バイナリを検索します。
/usr/bin/X11/xauth
/usr/X/bin/xauth
/usr/X11R6/bin/xauth
/usr/bin/X/xauth
/usr/openwin/bin/xauth
/usr/bin/xauth
xauth バイナリが別の場所に存在する場合は、その場所を /opt/tarantella/var/serverresources/expect/vars.exp
ログインスクリプトに追加する必要があります。「set xauthcmds
」で始まる行を探してください。
xauth バイナリが 1 つの場所にしか存在しない場合は、vars.exp
ログインスクリプトからほかの場所を削除することによってアプリケーションの起動を高速化できます。
4.9.3.3: ユーザーはアプリケーションサーバーに UNIX システムのアカウントを持っていますか。
ユーザーがアプリケーションを起動すると、X プロトコルエンジンプロセスは cookie を生成し、それをアプリケーションサーバー上のそのユーザーのホームディレクトリ内の .Xauthority
ファイル内に格納します。Cookie は、ユーザーが X ディスプレイに接続する権限を持っているかどうかを検証するために使用されます。
ユーザーがホームディレクトリを持っていない場合は、cookie をユーザーの .Xauthority
ファイルに格納できないため、そのユーザーを検証できません。
次のいずれかの操作を行えます。
アプリケーションサーバー上にそのユーザーのホームディレクトリを作成します。
X 認証を無効にします
Administration Console の「グローバル設定」 → 「セキュリティー」タブで、「X ディスプレイの X 認証」チェックボックスの選択を解除します。または、次のコマンドを実行します。
$ tarantella config edit --security-xsecurity 0
アプリケーションサーバー上の設定ファイルを編集して、Cookie が一時ディレクトリに保存されるようにします。
アプリケーションサーバー上の /etc/profile
ファイルに次の行を追加します。
XAUTHORITY=/tmp/.Xauthority.$LOGNAME export XAUTHORITY
アプリケーションサーバー上で、次の SSH デーモンの構成ファイル /etc/ssh/sshrc
を作成します。
HOME=/tmp XAUTHORITY=$HOME/.Xauthority.$USER export XAUTHORITY if read proto cookie && [ -n "$DISPLAY" ] then if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ] then # X11UseLocalhost=yes echo add unix:`echo $DISPLAY | cut -c11-` $proto $cookie else # X11UseLocalhost=no echo add $DISPLAY $proto $cookie fi | /usr/openwin/bin/xauth -q - fi
アプリケーションが約 2 分後に予期せずにユーザーに表示されなくなる場合は、プロキシサーバーの接続がタイムアウトしている可能性があります。アクティビティーが何も行なわれない接続については、プロキシサーバーが一定時間の経過後にその接続を停止します。
SGD は、接続を開いたままにするために keepalive パケットを送信します。この間隔は、デフォルトでは 100 秒です。アプリケーションが表示されなくなる場合は、接続を開いたままにするために keepalive パケットを送信する頻度を上げることができます。
Administration Console で、アプリケーションオブジェクトの「グローバル設定」 → 「通信」タブに移動し、「AIP keepalive の頻度」をデフォルト値より小さい値 (たとえば、60) に設定します。
または、次のコマンドを実行します。
$ tarantella config edit --sessions-aipkeepalive secs
この属性への変更を有効にするには、アレイ内のすべての SGD サーバーを再起動する必要があります。
ユーザーがアプリケーションを閉じてもアプリケーションが終了しない場合は、まずアプリケーションオブジェクトの設定を確認します。「セッション終了設定の確認」を参照してください。
OpenOffice アプリケーションに関する問題をトラブルシューティングするには、「OpenOffice アプリケーションが閉じない」を参照してください。
Windows アプリケーションの問題をトラブルシューティングするには、「Windows アプリケーションが閉じない」を参照してください。
UNIX デスクトップセッションの問題をトラブルシューティングするには、「ログアウト後に UNIX デスクトップセッションが閉じない」を参照してください。
Administration Console で、アプリケーションオブジェクトの「起動」タブに移動し、「セッション終了」属性の値を確認します。
「表示中のウィンドウがない」が選択されている場合、アプリケーションセッションは、表示中のウィンドウがない状態になった時点で終了します。
OpenOffice アプリケーションを閉じても、アプリケーションセッションが閉じないことがあります。これは、OpenOffice が、ほかの OpenOffice コンポーネントが起動されるとフォークされる 1 つのプロセスを使用するためです。
Administration Console で、アプリケーションオブジェクトの「起動」タブに移動し、「セッション終了」属性を「最後のクライアントの終了」に設定します。「起動接続をオープンしたまま保持」チェックボックスを選択します。
Microsoft Windows リモートデスクトップセッションホスト上でアプリケーションを実行している場合は、アプリケーションを閉じてもセッションが閉じるとは限りません。これは、Windows 用の SGD 拡張モジュールが引き続き実行されているためです。これを解決するには、特定のシステムプロセスを無視するように SGD 拡張モジュールを構成することにより、この拡張モジュールが閉じるようにします。これを行うには、アプリケーションサーバー上のレジストリ内の HKEY_LOCAL_MACHINE\Software\Sun Microsystems, Inc.\Enhancement Module for Windows
キーの System processes
値を編集します。この値は、SGD 拡張モジュールが無視できる .exe
バイナリのコンマ区切りリストを含む文字列です。この値を修正し、セッションのクローズ失敗時に実行されていたプロセスをそのリスト内に含める必要があります。それには、クローズに失敗したセッションが存在している間にタスク マネージャーを開き、「プロセス」タブに移動します。実行中のすべての .exe
プロセスのリストを作成します。ただし、次のプロセスは含めないでください。
clipsrv.exe
conime.exe
csrss.exe
EventLog.exe
lmsvcs.exe
lsass.exe
MsgSvc.exe
nddeagnt.exe
netdde.exe
NETSTRS.EXE
os2srv.exe
proquota.exe
rdpclip.exe
screg.exe
smss.exe
spoolss.exe
ttaswm.exe
userinit.exe
wfshell.exe
win.com
winlogon.exe
1 つのアプリケーションセッションを実行している場合は、System processes
レジストリ設定を編集したあとでも、そのセッションがまだ終了しないことに気付く場合があります。セッションを強制的に終了させるには、HKEY_LOCAL_MACHINE\Software\Sun Microsystems, Inc.\Enhancement Module for Windows
キーの Logoff application sessions
設定を修正し、その DWORD 値を 1
に変更します。
デスクトップの「スタート」メニューを使用してアプリケーションからログアウトすると、フルスクリーンのデスクトップセッションとして設定された X アプリケーションが閉じない場合があります。たとえば、アプリケーションからログアウトしたあとに、デスクトップアプレットが開いたままになる場合があります。その後、アプリケーションウィンドウのプルダウンヘッダーを使用してアプリケーションを閉じる必要があります。
この回避方法として、アプリケーションが閉じられたときにルートウィンドウから TTA_SESSION_STATE
プロパティーが削除されるように、X アプリケーションオブジェクトの「アプリケーションコマンド」(--app
) 属性を変更します。
次の例は、Java Desktop System デスクトップセッションで「アプリケーションコマンド」を変更する方法を示しています。
次のように簡単なシェルスクリプトを作成します。
#! /bin/sh /usr/dt/config/Xsession.jds /usr/openwin/bin/xprop -root -remove TTA_SESSION_STATE
そのスクリプトを SGD サーバー上の場所 (/usr/local/bin/launch.sh
など) に保存します。
Administration Console で、X アプリケーションオブジェクトの「起動」タブに移動し、スクリプトのパスを使用するように「アプリケーションコマンド」フィールドを編集します。
または、次のコマンドを実行します。
$ tarantella object edit --name objname
--app "/usr/local/bin/launch.sh"
デフォルトでは、ユーザーは Webtop 上でアプリケーションのリンクを Shift キーを押しながらクリックすることによって、SGD に強制的に「アプリケーション認証」ダイアログを表示させることができます。これにより、ユーザーは異なるユーザー名とパスワードでアプリケーションを起動できます。
Shift キーを押しながらのクリック動作を無効にすることができます。Administration Console で、「グローバル設定」 → 「アプリケーション認証」タブに移動し、「Shift キーを押しながらクリックしたとき」チェックボックスの選択を解除します。または、次のコマンドを実行します。
$ tarantella config edit --launch-showauthdialog system
Shift キーを押しながらのクリック動作を無効にすることは、パスワードに問題があるか、パスワードが存在しない場合にだけ「アプリケーション認証」ダイアログが表示されることを意味します。
Windows リモートデスクトップサービスを使用している場合は、ユーザーが SGD またはリモートデスクトップセッションホストからユーザー名とパスワードの入力を求められることがあります。
SGD が常にユーザーにユーザー名とパスワードの入力を求める場合、この問題は通常、ドメイン名が見つからないために発生します。パスワードキャッシュ内にドメイン名を含むユーザーのエントリがない場合は、「アプリケーション認証」ダイアログが表示されます。
この問題を解決するには、パスワードキャッシュに詳細情報を保存するときに、ドメイン名を指定する必要があります。ドメイン名の指定は、アプリケーションサーバーがドメインに属していない場合にも行います。
ドメイン名を設定するもっとも簡単な方法は、アプリケーションサーバーオブジェクトまたはアプリケーションオブジェクトで「ドメイン名」属性を使用することです。「アプリケーション認証」ダイアログでは、ユーザー独自のドメイン名を指定することもできます。「Windows ドメインとパスワードキャッシュ」を参照してください。
SGD は、ユーザーを認証するために、ユーザー名とパスワードの情報を Windows リモートデスクトップサービスに送信します。認証が失敗した場合、Windows がユーザーに再度入力を要求します。認証が成功したか失敗したかを示す情報が SGD に返されないため、それが正しいかどうかにかかわらず、詳細情報は SGD パスワードキャッシュ内に残ります。
ユーザーが間違ったユーザー名、パスワード、またはドメイン名をパスワードキャッシュに保存した可能性があります。
この問題を解決するには、アプリケーションを起動する際に、Shift キーを押しながらリンクをクリックする必要があります。これにより、「アプリケーション認証」ダイアログが表示され、ユーザーは自身のユーザー名、パスワード、およびドメイン名を訂正できます。あるいは、パスワードキャッシュ内のユーザーのエントリを削除して、次回のアプリケーション起動時に SGD がユーザーに入力を要求します。
リモートデスクトップセッションホストはまた、ユーザーがログインしたときに常にパスワードの入力を要求するようにも構成できます。デフォルトでは、Microsoft Windows Server 2003 以降ではパスワードの入力が要求されません。「認証の設定」を参照してください。
SGD が別のサービスで使用されている X ディスプレイポートを使用しようとしている場合は、アプリケーションの起動に予想より長い時間がかかることがあります。アプリケーションの起動は最終的に正常終了します。
これを解決するには、このポートを X プロトコルエンジンで使用しないように除外します。
Administration Console で、アレイ内の各 SGD サーバーの「プロトコルエンジン」、「X」タブに移動し、「コマンド行引数」フィールドに「-xport
portnum
」と入力します。ここで、portnum
は除外する TCP ポート番号です。
または、次のコマンドを実行します。
$ tarantella config edit --xpe-args "-xport portnum
"
複数のポートを除外するには、次のように、-xport
portnum
を複数回指定できます。
$ tarantella config edit \ --xpe-args "-xportportnum_1
" "-xportportnum_2
" "-xportportnum_3
"
行なった変更は、新しい X プロトコルエンジンでのみ有効になります。既存の X プロトコルエンジンに影響はありません。
ユーザーでアプリケーションに関する問題が発生している場合は、Administration Console を使用してユーザーのアプリケーションセッションを検索したあと、それをシャドウイングすることができます。シャドウイングを使用すると、ユーザーと SGD 管理者がアプリケーションを同時に表示したり、使用したりすることができます。
シャドウイングを使用するには、SGD 管理者が ttaserv
グループのメンバーである必要があります。
ユーザーのアプリケーションセッションを検索するには、そのユーザープロファイルオブジェクトの「アプリケーションセッション」タブに移動します。または、アプリケーションオブジェクトの「アプリケーションセッション」タブに移動します。これにより、現在そのアプリケーションを実行しているユーザーが一覧表示されます。
「アプリケーションセッションリスト」テーブル内のアプリケーションセッションを選択します。シャドウイングを開始するには、「シャドウイング」ボタンをクリックします。
ユーザーの画面に、セッションのシャドウイングを許可するかどうかを確認するダイアログボックスが表示されます。ユーザーが同意すると、管理者の画面に新しいウィンドウが開き、実行中のアプリケーションが表示されます。管理者とユーザーの双方が、マウスポインタを操作したりアプリケーションを使用したりできます。
ユーザーの問題を解決したら、シャドウイングウィンドウを閉じますが、アプリケーションは閉じないでください。ユーザーの画面に、現在このセッションをだれもシャドウイングしていないことを示すダイアログボックスが表示されます。
「アプリケーションセッション」タブには、セッションが開始された日付と時刻、セッションが中断されているか、現在アクティブ状態であるかなど、その他のアプリケーションセッション情報も表示されます。
シャドウイングできるのは、Windows アプリケーションと X アプリケーションだけです。アプリケーションを中断してはいけません。
ユーザーのアプリケーションセッションで複数のアプリケーションがリソースを共有して使用している場合は、そのセッションをシャドウイングすると、リソースを共有しているすべてのアプリケーションが表示されます。シャドウイングウィンドウのボタンバーを使用すれば、アプリケーションを切り替えることができます。
また、tarantella emulatorsession shadow コマンドを使用して、コマンド行からユーザーのセッションをシャドウイングすることもできます。
低帯域幅の接続でシャドウイングしているときに表示の更新に問題が発生する場合、その解決方法の詳細については、「低帯域幅の接続でシャドウイングしているときの表示の更新の問題」を参照してください。
キオスクウィンドウに表示されるように設定されているアプリケーションを元のディスプレイよりも大きいディスプレイまたは小さいディスプレイで再開した場合、アプリケーションは画面のサイズと正確には一致しなくなります。
最適な解決策は、RANDR 拡張機能を使用してセッションサイズ変更を自動的に処理することです。あるいは、SGD によってキオスクウィンドウが画面に合わせて確実に拡大縮小されるように、--scalable
属性を構成することもできます。
次のいずれかを実行します。
Administration Console で、アプリケーションオブジェクトの「プレゼンテーション」タブに移動し、「ウィンドウのサイズ」を「RandR 拡張機能」に設定します。
または、次のコマンドを実行します。
$ tarantella object edit --name obj
--xrandr true
RANDR 拡張機能がアレイで有効になっている必要があります。「SGD アレイでの RANDR 拡張機能の有効化」を参照してください。
Administration Console で、アプリケーションオブジェクトの「プレゼンテーション」タブに移動し、「ウィンドウのサイズ」を「ウィンドウに合わせて拡大縮小する」に設定します。
または、次のコマンドを実行します。
$ tarantella object edit --name obj
--scalable true
アプリケーションオブジェクトのパフォーマンス設定を変更すると、アプリケーションセッションでのアニメーション効果の表示が改善される場合があります。
Administration Console で、アプリケーションオブジェクトの「パフォーマンス」タブに移動し、「コマンドの実行」属性を「順番に」に設定します。「遅延更新」チェックボックスを選択解除します。
または、次のコマンドを実行します。
$ tarantella object edit --name obj
\
--execution inorder --delayed false
SGD では、メモリーのオーバーヘッドを削減するために、類似したアプリケーションでリソースを共有できます。ただし、UNIX デスクトップセッションでは、これによってアプリケーションの起動時や使用時に問題が発生する場合があります。
GNOME デスクトップや Java Desktop System デスクトップなどの UNIX デスクトップセッションでは、X アプリケーションオブジェクトの共有リソースを無効にすることをお勧めします。
Administration Console で、X アプリケーションオブジェクトの「パフォーマンス」タブに移動し、「類似セッション間でリソースを共有」チェックボックスの選択を解除します。
または、次のコマンドを実行します。
$ tarantella object edit --name obj
--share false
Mac OS X クライアントデバイスのユーザーが SGD アプリケーションを使用しているときに、次のキーボードの問題が発生することがあります。
Apple キーボード上に必要なキーが存在しません
Apple キーボード上のキーを押しても、予期した文字が生成されません
Apple キーボード上のキーを押しても、何も効果がありません
これらの問題の回避方法は、アプリケーションのタイプによって異なります。
デフォルトでは、SGD は、クライアントキーボードのキー配列を自動的に検出しようとします。ただし、ユーザーは、次のようにクライアントプロファイルを編集することによって代わりのキー配列を構成できます。
「クライアントキーボード配列の一致を試行」の設定を無効にします
クライアントキーボードに適した「キーボード配列」設定を選択します
代わりのキー配列は、すべてのクライアントキーボードタイプで使用できるわけではありません。
クライアントデバイス上の Apple キーボードの配列と、アプリケーションサーバー上で構成されているキー配列の間の非互換性のために問題が発生する場合があります。
たとえば、ユーザーが Apple UK キーボードを使用して、Microsoft UK キーボードからのキー押下が必要な Windows アプリケーションにアクセスする可能性があります。次のキー配列の違いのために、ユーザーでキーボードの問題が発生する場合があります。
次の Apple キーは、標準の Microsoft UK 配列には存在しません。
§
±
次の Microsoft キーは、標準の Apple UK 配列には存在しません。
#
~
これらの欠けているキーは通常、キーの組み合わせを使用して生成できます。詳細は、Apple のドキュメントを参照してください。
ほかの英数字キーやファンクションキーがキーボード上の異なる場所にあるか、または期待どおりに機能しないことがあります。
Apple キーボードの問題に関してさらにアドバイスが必要な場合は、Oracle サポートまでお問い合わせください。
X アプリケーションでフォントの問題がユーザーに発生している場合は、次のことを確認してください。
Questions
Questions and Answers
Administration Console で、X アプリケーションオブジェクトの「クライアントデバイス」タブに移動し、「モニターの解像度」属性の値を確認します。アレイ内の各 SGD サーバーの「プロトコルエンジン」 → 「X」タブを表示し、「モニターの解像度」属性の値を確認します。
「モニターの解像度」属性は、この情報を要求する X アプリケーションに SGD が報告するモニターの解像度 (1 インチあたりのドット数) を指定するために使用されます。使用するフォントサイズを決めるために、一部の X アプリケーションでは、この値が必要となります。
デフォルトの解像度では、X アプリケーションが通常選択するフォントよりもサイズの大きいフォントが選択される場合があります。この現象が生じた場合には、小さい値 (たとえば、75) を指定して、解像度を下げてください。
Administration Console で、アレイ内の各 SGD サーバーの「プロトコルエンジン」 → 「X」タブに移動し、「フォントパス」属性が正しいことを確認します。
SGD には、いくつかの「X フォント」が用意されています。また、次のことも実行できます。
独自の X フォントを構成します。「独自の X フォントを使用するように SGD を構成する方法」を参照してください。
フォント別名を使用して、インストール済みのフォントにマップします。「フォント別名の使用」を参照してください。
X アプリケーションを High Color で表示するときに、次のような問題が発生することがあります。
X アプリケーションが実行に失敗し、「Cannot Allocate Enough Color Planes」などのエラーで終了した場合、そのアプリケーションではおそらく 8 ビットカラーのみが表示されます。アプリケーションの表示仕様を確認し、アプリケーションオブジェクトの発色数を調整します。
Administration Console で、アプリケーションオブジェクトの「プレゼンテーション」タブに移動し、「発色数」を「8 ビット - 256 色」に設定します。
または、次のコマンドを実行します。
$ tarantella object edit --name obj
--depth 8
16 ビットまたは 24 ビットカラーのアプリケーションの表示に問題がある場合は、アプリケーションオブジェクトのカラー品質を変更します。
Administration Console で、アプリケーションオブジェクトの「パフォーマンス」タブに移動し、「カラー品質」を 16 ビットアプリケーションの場合は 16 ビットに、24 ビットアプリケーションの場合は 24 ビットに設定します。
または、次のコマンドを実行します。
$ tarantella object edit --name obj
--quality 16 | 24
帯域幅が重要な場合は、アプリケーションオブジェクトのカラー品質を下げてみてください。
Administration Console で、X アプリケーションオブジェクトの「パフォーマンス」タブに移動し、「カラー品質」を 9 ビットまたは 6 ビットに設定します。
または、次のコマンドを実行します。
$ tarantella object edit --name obj
--quality 9 | 6
この設定変更を行なっても、帯域幅が節約されるという絶対的な保証はありません。また、アプリケーションの表示に悪影響を及ぼす可能性もあります。
たとえば CDE デスクトップから、16 ビットまたは 24 ビット High Color の X アプリケーションセッション内で 8 ビットアプリケーションを実行すると、そのアプリケーションが "Cannot find a matching 8-bit PseudoColor visual"
などのエラーで終了することに気付く場合があります。
この問題を解決するには、X アプリケーションの発色数を変更して、複数の発色数がサポートされるようにします。
Administration Console で、X アプリケーションオブジェクトの「プレゼンテーション」タブに移動し、「発色数」を「16/8 ビット - 数千色」または「24/8 ビット - 数百万色」に設定します。
8 ビットアプリケーションのプライマリ発色数を 8 ビットにする必要がある場合は、「発色数」を「8/16 ビット - 数千色」または「8/24 ビット - 数百万色」に設定します。
または、次のコマンドを実行します。
$ tarantella object edit --name obj
--depth 16/8 | 24/8
これらの設定を使用すると、メモリーとパフォーマンスに影響があります。
発色数を変更しても依然としてアプリケーションが終了する場合は、回避方法として、そのアプリケーションの別の X アプリケーションオブジェクトを作成し、発色数を 8 ビットに設定してください。
クライアントウィンドウ管理を使用するように設定されている X アプリケーションの使用時に、ウィンドウが切り取られて表示される場合、ディスプレイの解像度が適切な解像度より高いことが原因です。
これを解決するには、X プロトコルエンジンのディスプレイ解像度を増やします。
Administration Console で、アレイ内の各 SGD サーバーの「プロトコルエンジン」 → 「X」タブに移動し、「クライアントウィンドウのサイズ」設定を変更します。「高さの最大値」および「幅の最大値」フィールドに、必要とする最高のディスプレイ解像度を入力します。
「幅の最大値」および「高さの最大値」属性を増やすと、クライアントデバイスと SGD サーバーの両方で「クライアントウィンドウ管理」アプリケーションのメモリー要件が増加します。
または、次のコマンドを実行します。
$ tarantella config edit --array \ --xpe-cwm-maxwidthpixels
\ --xpe-cwm-maxheightpixels
「クライアントウィンドウ管理」の「ディスプレイタイプ」を使用して構成されたデスクトップセッションで入力方式エディタ (IME) を使用しているときに、そのセッションをそれより小さなモニター上で再開すると、そのあと IME を使用できなくなることがあります。
これを解決するには、デスクトップセッションの RANDR 拡張機能を有効にします。より小さなモニターに切り替えると、セッションサイズ変更が IME ウィンドウに自動的に通知されます。
アプリケーションオブジェクトの RANDR を有効にするには、Administration Console の「プレゼンテーション」タブに移動し、「ウィンドウのサイズ: RandR 拡張機能」チェックボックスを選択します。
または、次のコマンドを実行します。
$ tarantella object edit --name obj
--xrandr 1
RANDR が、アレイでグローバルに有効になっている必要があります。「SGD アレイでの RANDR 拡張機能の有効化」を参照してください。
SGD に低帯域幅で接続しているユーザーをシャドウイングすると、表示の更新の問題が発生することがあります。
この問題を解決するには、次の手順で X プロトコルエンジンのキューの長さを増やし、コマンドの実行を最適化します。
Administration Console で、アレイ内の各 SGD サーバーの「プロトコルエンジン」 → 「X」タブに移動し、「コマンド行引数」フィールドに「-mql 8192
」と入力します。
または、次のコマンドを実行します。
$ tarantella config edit --xpe-args "-mql 8192"
行なった変更は、新しい X プロトコルエンジンでのみ有効になります。既存の X プロトコルエンジンに影響はありません。
Administration Console で、シャドウイングされたアプリケーションの「パフォーマンス」タブに移動し、「コマンドの実行」属性を「最適化」に設定します。
または、次のコマンドを実行します。
$ tarantella config edit --name obj
--execution optimized
行なった変更は、シャドウイングされたアプリケーションを次に起動したときに有効になります。
マウスドラッグ遅延の問題により、ドローイングアプリケーションの使用時にユーザーエクスペリエンスが低下する場合があります。
これを解決するには、SGD Client のマウスドラッグ遅延の設定を減らします。ユーザーのクライアントプロファイルの <localsettings>
セクション内に新しい <mousethrottledelaywithbutton>
エントリを追加します。<localsettings>
セクションがクライアントプロファイルに存在しない場合は、新しいセクションを作成します。
たとえば、マウスドラッグ遅延を 10 ミリ秒に設定するには、次のように入力します。
<localsettings> <mousethrottledelaywithbutton>10</mousethrottledelaywithbutton> ... <localsettings>
マウスドラッグ遅延のデフォルト値は 100 ミリ秒です。
クライアントプロファイルに対する変更が反映されるのは、新規ユーザーセッションだけです。
Windows アプリケーションサーバーでタイムゾーンのリダイレクトが有効になっているときに、Windows アプリケーションに表示されるタイムゾーン名が正しくない場合があります。この問題は、UNIX プラットフォームのクライアントデバイスに Windows アプリケーションを表示したときに見られます。
これを解決するには、クライアントデバイス上の $TZ
タイムゾーン環境変数を、ユーザーの場所を示す正しい値に手動で設定します。tzselect コマンドを使用すると、ある地理的な場所で可能性のあるタイムゾーンの値を一覧表示できます。
Windows アプリケーションサーバーでのタイムゾーンリダイレクトの使用については、「タイムゾーンのリダイレクト」を参照してください。
Windows アプリケーションを実行している場合は、ユーザーでクライアントアクセスライセンス (CAL) に関する問題が発生することがあります。このセクションには、CAL を使用しているときの問題を診断して解決するのに役立ついくつかのトラブルシューティングのトピックが含まれています。
SGD Client が CAL を使用している場合、メッセージは SGD Client ログファイルに書き込まれます。このログファイルを表示して、次の内容に関するメッセージを探してください。
ライセンスストアの場所
ライセンスストアへのアクセスの問題
無効なライセンスのエラー
Sun Ray データストアのエラー
デフォルトの SGD Client ログファイルの場所については、「SGD Client のロギング」を参照してください。
クライアントデバイスが複数のユーザーで共有されている場合は、ライセンスの過剰な消費を避けるために、CAL を共有された場所に格納するようにしてください。
最適な結果を得るには、「システム規模のインストール」の説明に従って、SGD Client をシステム規模の場所に手動でインストールしてください。これにより、CAL が、表4.1「クライアントデバイス上の CAL を格納するためのデフォルトの場所」に一覧表示されているデフォルトのライセンスの場所のいずれかに格納されることが保証されます。デフォルトのライセンスの場所は、すべてのユーザーから書き込み可能です。
Linux、Oracle Solaris、および Mac OS X プラットフォームの場合は、クライアントプロファイルの <localsettings>
セクション内の <calstorepath>
エントリを使用して、デフォルトのライセンスの場所をオーバーライドできます。これについては、「Microsoft Windows リモートデスクトップサービスのライセンス」で説明されています。
ライセンスを取得するために、SGD Client は Sun Ray データストアにアクセスするための必要なアクセス権を持っている必要があります。SGD Client バイナリで、次の要件が満たされている必要があります。
ファイルが Windows Connector グループ (utwc
) に属している必要があります
ファイルの setgid
ビットが設定されている必要があります
SGD Client をシステム規模の場所にインストールすると、SGD Client に必要なアクセス権が自動的に構成されます。「システム規模のインストール」を参照してください。
Sun Ray データストアへのアクセス時のエラーは、SGD Client ログファイル内に記録されます。「CAL のロギング」を参照してください。
このセクションには、動的起動に使用されるブローカに関する問題をトラブルシューティングするためのいくつかのトピックが含まれています。
アプリケーションの起動時、チューザページに多数のアプリケーションサーバーが表示されるため、必要なアプリケーションサーバーの選択が困難になる場合があります。
ユーザー定義の SGD ブローカには、アプリケーションサーバーのリストを構成したり、ユーザーが SGD で構成されたアプリケーションサーバーのみを指定するように制限したりするために使用できる「仮想サーバーブローカパラメータ」(--vsbparams
) 属性のためのパラメータが含まれています。
Administration Console で、動的アプリケーションサーバーオブジェクトの「一般」タブに移動し、「仮想サーバーブローカパラメータ」フィールドのオプションを次のように構成します。
チューザページ内のアプリケーションサーバーのリストを非表示にします。
hideAppservers
ユーザーはチューザページにあるテキストフィールドにホスト名を入力することによって、引き続きアプリケーションサーバーを指定できることに注意してください。
ユーザー指定のアプリケーションサーバーがローカルリポジトリ内に存在することを確認します。
checkAppserver
ユーザー指定のアプリケーションサーバーがローカルリポジトリ内に存在しない場合は、エラーメッセージが表示されます。
checkAppserver
パラメータを使用すると、ユーザーは、まだローカルリポジトリで構成されていないアプリケーションサーバーを指定できなくなります。
checkAppserver
パラメータを有効にした場合、ユーザーは、チューザページでアプリケーションサーバーオブジェクトの共通名を入力する必要があります。
アプリケーションサーバーのリストを非表示にし、かつユーザー指定のアプリケーションサーバーがローカルリポジトリ内に存在することを確認すします。
hideAppservers,checkAppserver
VDI ブローカは、java.util.logging
パッケージを使用します。このブローカは Tomcat JSP コンテナ上で実行されるため、SGD サーバー上の次のファイルを編集することによってロギングを構成できます。
/opt/tarantella/webserver/tomcat/
tomcat-version
/conf/logging.properties
デフォルトでは、ログ出力は次のファイルに書き込まれます。
/opt/tarantella/webserver/tomcat/
tomcat-version
/logs/vdibroker.date
.log
VDI ブローカのロギングレベルを変更するには、logging.properties
ファイル内の次のエントリを編集します。
com.oracle.sgd.vsbim.level=<LOG_LEVEL> ... 1vdibroker.org.apache.juli.FileHandler.level=<LOG_LEVEL>
ここで、<LOG_LEVEL>
は必要なロギングレベルです。
変更を行なったあと、SGD サーバーを再起動します。
# tarantella restart
ロギングレベルの構成についての詳細は、Oracle Java ドキュメントを参照してください。
VDI ブローカを使用して Oracle VDI インストールと統合すると、次の証明書の問題が発生することがあります。
VDI 証明書が SGD サーバー上に正しくインポートされません。「VDI 証明書が正しくインポートされない」を参照してください。
VDI 証明書が完全指定名を使用していません。「VDI 証明書が完全指定のドメイン名を使用していない」を参照してください。
VDI 証明書が SGD サーバー上に正しくインポートされない場合は、VDI サーバーへの接続が拒否され、次のようなエラーメッセージが表示されることがあります。
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
次の問題を確認してください。
証明書がインポートされていません。デフォルトでは、VDI Web サービスは自己署名付き証明書を使用します。SGD サーバーが自己署名付き証明書を信頼できるようにするには、その証明書を SGD サーバー上のトラストストアにインポートする必要があります。
間違った証明書がインポートされています。Oracle VDI は、さまざまなコンポーネントのために複数の自己署名付き証明書を作成します。VDI ブローカは、Web サービス証明書を使用します。
VDI 証明書は、証明書の共通名 (CN) 属性に完全指定のドメイン名を使用しない可能性があります。preferredhosts
または failoverhosts
パラメータに、完全指定である VDI ホスト URL を構成すると、接続が拒否される可能性があります。これは、証明書の共通名が、接続しようとしているホストの名前に一致しないためです。
次のようなエラーメッセージが表示されることがあります。
java.security.cert.CertificateException: No name matching example.uk.oracle.com found … java.io.IOException: HTTPS hostname wrong: should be <example.uk.oracle.com>
回避方法として、preferredhosts
や failoverhosts
に入力するホスト名を、対応する Web サービス証明書の共通名 (CN) に確実に一致させるようにします。
より優れた解決策は、VDI 証明書が確実に完全指定のドメイン名を使用し、かつ信頼できる証明書発行局 (CA) によって署名されるようにすることです。