この付録では、Solaris の使用時に発生するトラブルについて、そのいくつかを解決するための資料を提供します。これらのトラブルの解決にあたっては、この付録全体を通読されることをお薦めします。この付録の構成は、DeskSet、OpenWindows、および ワークスペースプロパティのカテゴリに分かれています。
ここに収められている情報の中には、UNIX オペレーティングシステムについての基礎知識を必要とするものがあります。UNIX オペレーティングシステムに関連する問題の診断や訂正の方法を理解できない場合、担当のシステム管理者、または UNIX に精通している人に相談してください。
この節では、DeskSet で利用できるツールについて説明します。
バインダの実行中にはユーザデータベースがロックされるため、一度に 1 つのバインダしか実行できません。バインダが起動できず、しかもユーザデータベースに書き込むためのパーミッションがないことを示すメッセージがコンソールに表示された場合、ユーザが他のバインダを現在実行中である可能性があります。
バインダエントリに対応すると思われるファイル形式エントリが表示されない場合、その理由はおそらく、バインダがそのバインダエントリを読み込む前に、そのエントリのコピーを読み込んだためです。重複したエントリがあると、バインダは最初に読み込んだエントリだけを使います。バインダが読み込んだ最初のエントリは、ベースウィンドウにあるスクローリングリストの最初のバインダエントリと必ずしも一致しません。したがって、 「コピー」ボタンを使ってエントリを複写する際には、注意が必要です。特定のバインダエントリ用のエントリが表示されない場合は、重複したエントリを見つけて削除してください。
計算ツールが、ゼロ除算などのエラーを検出した場合、Error という語が表示されます。計算ツールにこれ以降の計算を実行させるには、Clr キーで計算ツールをクリアしなければなりません。
この節では、カレンダマネージャの基本的なトラブルについて説明します。
カレンダマネージャは、次の 2 つから構成されます。
rpc.cmsd (カレンダマネージャサービス) と呼ばれるデータベースマネージャ。これは、カレンダマネージャ用の情報を管理します。
cm と呼ばれるカレンダマネージャのアプリケーション自身。
カレンダマネージャのアプリケーションは、カレンダマネージャサービスがなくては機能しません。
カレンダマネージャがアポイントメントを表示しない場合、またはコンソールウィンドウに RPC のタイムアウトメッセージが表示された場合、rpc.cmsd が動作していないことがあります。ユーザの構成を検査するには、次の手順に従ってください。
コマンドツールまたは シェルツールをオープンします。
コマンドツールやシェルツールについては、第 6 章「コマンドツール、シェルツール、 コンソールウィンドウ」を参照してください。
システムプロンプトに続けて、 ps -e | grep rpc.cmsd と入力して Return キーを押します。
これは、文字列 rpc.cmsd が収められているすべてのプロセスを表示します。
ウィンドウに表示されたリストを参照します。
カレンダマネージャのサービスプロセスが収められたリストを図 A-1 に示します。ps リストのエントリ grep rpc.cmsd は無視できます。
rpc.cmsd プロセスを実行していない場合、次のステップに従ってください。
カレンダマネージャのアプリケーションを実行している場合、ウィンドウメニューから「終了」を選択してカレンダマネージャを終了してください。
ルートになります。
システムプロンプトに続けて、vi /etc/inetd.CONF と入力します。
エントリ Rpc.cmsd を捜します。
指定されたパス名が正しく、かつ、そのパス名に Rpc.cmsd エントリが存在することを確認してください。存在しない場合、Rpc.cmsd の存在する場所を指すように、パスを変更してください。次のように入力して、inetd のプロセス ID を表示してください。
ps -e | grep inetd |
次のように入力して、inetd.CONF ファイルを再び読み込んでください。
kill -1 inetd-pid |
カレンダマネージャを再起動します。
カレンダマネージャサービスが現在動作中であることを確認するため、 ps -e | grep rpc.cmsd と入力して、Return キーを押します。
SunOS をアップグレードする場合、下記のディレクトリをバックアップして、その情報を保存しなければなりません。/var/spool/calendar
どのバックアップメディアを使うかはユーザの自由です。オペレーティングシステムのアップグレードが終了してから、このディレクトリを復元してください。
アポイントメントが表示されない場合、必要に応じて、インストールスクリプトを実行したことを確認してください。詳細については、「RPC 問題とカレンダマネージャのインストール」を参照してください。下記の手続きを行う前に、まず、カレンダマネージャの再起動を行なってください。
それでもアポイントメントが表示されず、しかもカレンダマネージャのヘッダに文字列 NO NAME が表示されている場合、おそらく /usr/spool/calendar ディレクトリおよびファイルのパーミッションが不正です。下記のステップで、パーミッションを確認してください。
ls -lsa /usr/spool と入力し、ディレクトリ /usr/spool/calendar のパーミッションを検査します。
パーミッションは、正確に drwxrwsrwt でなければなりません。これはデーモングループ内のデーモンが所有していなければなりません (必要ならば、システム管理者に確認してパーミッションを変更してください)。
カレンダデータベースのパーミッションを検査するには、次のように入力します。
ls -lsa /usr/spool/calendar/callog.<ユーザ名> |
<ユーザ名> はユーザの名前に置き換えてください。たとえば、次のように入力します。
ls -lsa /usr/spool/calendar/callog.egret |
パーミッションは、正確に -r--rw---- でなければなりません。また、このファイルはユーザとデーモングループによって所有される必要があります。
カレンダマネージャのリモートアクセスに関するトラブルには、基本的に 2 つの症状があります。
ブラウザアクセスできると考えられるリモートカレンダを表示しようとするが、アポイントメント時間しか表示されない。
アクセスできると考えられるリモートカレンダ上で、アポイントメントを挿入、削除、または変更しようとするが、カレンダマネージャは、アポイントメントエディタのフッタ内に「アクセスは拒否されました ... 」というエラーメッセージを表示する。
これらのアクセス問題を処置しようとした場合、3 つの項目について調べてください。
メールドメインの概念を採用している NIS または DNS のシステムを使っている場合、ユーザドメイン内でカレンダを表示しようとしているか、または表示リスト内のドメインを指定したことを確認してください。たとえば、ユーザドメイン内でユーザ Rob のカレンダを表示しようとしている場合、Rob@host をそのまま指定できます。Eng と呼ばれるドメイン内にいて、Rob は Corp と呼ばれるドメイン内にある場合、表示リスト内に rob@host.Corp を指定する必要があります。
リモートカレンダの所有者がユーザにブラウズ、挿入、削除のアクセスを許可したことを確認してください。
アクセスを行うためには、次の 2 つの条件が満足されていなければなりません。
アクセスリスト内の名前は、user@host または単に user の形式でなければなりません。なお、アクセスリスト内の名前が単に user の場合、ネットワーク上でそのユーザ名の人にアクセスが許可されます。NIS または DNS のシステムを使っている場合、アクセスリスト内のユーザ名が、user@domain または user@name.domain の形式でリストされていないことを確認してください。
カレンダの所有者は、「アクセスリストとパーミッション」のプロパティウィンドウの「適用」ボタンの上でセレクトボタンでクリックしなければなりません。ユーザのワークステーションとリモートワークステーションの両方で、ユーザ ID とグループ ID を検査してください。これらの ID は、両方で一致しなければなりません。
次のように、各ワークステーション上でユーザ ID とグループ ID を決定してください。
ファイル /etc/passwd 内でパスワードエントリを探してください。
このファイルにエントリがある場合、ユーザ ID は 3 番目のフィールド (2 番目と 3 番目のコロンの間の数) です。グループ ID は 4 番目のフィールド (3 番目と 4 番目のコロンの間の数) です。たとえば、/etc/passwd ファイルのユーザ Egret のエントリが以下のような場合、
egret:X4y8r2Bg:3286:10:& West:/home/egret/:/bin/csh
ユーザ Egret のユーザ ID は 3286 であり、グループ ID は 10 です。 ユーザ ID とグループ ID の値は 0 〜 32767 でなければなりません。
NIS システムを使っており、しかもファイル /etc/passwd にエントリがなく、/etc/passwd の最後の行が「+」で始まる場合、NIS passwd エントリのエントリを検査してください。NIS のユーザエントリを決定するには、コマンドツールまたはシェルツールに ypmatch username passwd と入力してください。
たとえば、ユーザ Egret の NIS パスワードエントリを見つけるには、次のとおりに入力してください。
ypmatch egret passwd |
システムがユーザエントリで応答した場合、ユーザ ID は 3 番目のフィールドであり、グループ ID は 4 番目のフィールドです。
ワークステーションに第 2 カレンダを追加したい場合、そのカレンダ用のダミーユーザを作成する必要があります。たとえば、ユーザの作業グループ全体に対するアポイントメントに、第 2 カレンダを追加したいことがあります。
ダミーユーザと新しいカレンダを作成するには、下記のステップを実行します。これらのステップは UNIX システム管理についての基礎的な理解を前提とするため、他の人の助けが必要になることもあります。ルートになって以下を実行してください。
第 2 カレンダを作成しようとするワークステーションの /etc/passwd ファイルにダミーエントリを追加します。
名前、ダミーユーザ ID 等を指定する必要があります。
cm および rpc.cmsd のプロセスを停止します。
新しいダミーユーザとしてログインし、新しいカレンダマネージャを起動します。
グループ用のアクセスリストとパーミッションを編集します。
カレンダ名をブラウズリストに追加します。
ログアウトし、自分自身のログイン名で再びログインします。
これで新しいカレンダを表示できます。
ユーザがワークステーション間を移動し、しかもユーザの実際のカレンダには常にアクセスしたい場合、各ワークステーションでカレンダマネージャを実行していなければなりません。複数のワークステーションからユーザのカレンダにアクセスするには、下記の手順を実行します。
ユーザの一次ワークステーションで、リモートワークステーションにあるユーザのカレンダに完全なアクセスリストのパーミッションを与えます。
たとえば、ユーザ Egret には、work という名前のワークステーションに実際のカレンダがあり、sea および ocean という名前のリモートワークステーションにアカウントとカレンダがあると想定します。このユーザは egret@sea と egret@ocean を自分のカレンダアクセスリストに追加し、これらのユーザにブラウズ、挿入、および削除の完全なパーミッションを与えます。方法については、第 5 章「カレンダマネージャ」を参照してください。
リモートワークステーションにログインしたとき、自分の実際のカレンダを表示します。
完全なアクセスパーミッションがあるため、すべてのアポイントメントの読み出しや、アポイントメントの変更などが可能になります。
前の例で、Egret が sea または ocean にログインすると、カレンダ egret@work を表示して、自分の実際のカレンダにアクセスできます。
リモートディスクから /usr/spool/calendar ディレクトリをマウントしないでください。これを行った場合、カレンダデータが失われることがあります。
現行バージョンの OpenWindows を動作させた後で、旧バージョンの OpenWindows を動作させた場合、旧バージョンのカレンダマネージャはユーザのアポイントメントデータファイルを読み込めません。この問題を避けるには、現行バージョンのカレンダマネージャを起動する前に、下記のファイルをバックアップしてください。
/usr/spool/calendar/callog.<ユーザ名>
旧バージョンのカレンダマネージャに戻る前に、ディレクトリおよびファイルのパーミッションを保持しながら、古いファイルを復元してください。ユーザのバージョンとは異なるバージョンで動作しているカレンダを表示した場合、正常に動作するはずです。
時計ツールの秒数表示は、システム性能に悪影響を与えることがあります。
ワークスペースの色が黒の場合、時計ツールがワークスペース上のアイコンのときに見えなくなります。時計ツールアイコンを、ワークスペースの色ではなく、ウィンドウのバックグラウンド色でペイントする方法については、clock のマニュアルページを参照してください。
この節では、Deskset のアプリケーションから別のアプリケーションにドラッグ&ドロップを試みるときに発生するエラーメッセージについて説明します。
サーバが一定時間内に受信アプリケーションと接続できない場合、このメッセージが表示されます。XView アプリケーションに対するデフォルトのタイムアウト値は 3 秒です。
ユーザの ‾/.Xdefaults ファイルに 1 行を追加することによって、この値は変更できます。この値を 5 秒に変更したい場合、
Selection.Timeout 5 |
という行を ‾/.Xdefaults ファイルに追加し、コマンド行から xrdb ‾/.Xdefaults と入力して、新しいタイムアウト値をサーバに設定してください。
受信アプリケーションのドラッグ&ドロップのターゲットが送信側に応答していない場合、このメッセージも表示されます。この場合、受信アプリケーションを再起動することによって、問題が解決します。
ドラッグされたオブジェクトがルートウィンドウにドロップされました。通常、この場合はファイルマネージャはそのアイテムがオープンされるとみなしますが、送信側アプリケーションはこれをエラーとみなします。
ドラッグ&ドロップのコネクションを確立しようとしているとき、原因不明の内部エラーが発生しました。
ドラッグ&ドロップを実行中に原因不明の内部エラーが発生しました。ドラッグ&ドロップ操作をもう一度試みてください。
この節では、ファイルマネージャに共通の問題点に対する解決策を説明します。
ファイルマネージャの「ファイル」メニューから「フォーマット」を使ってフロッピーディスクをフォーマットしようとしても正常に動作しない場合、ユーザのシステムはフォーマットプログラムが動作できるように設定されていない可能性があります。システム管理者に確認してください。
バインダでファイルのアイコンを変更しても、ファイルマネージャには変化がない場合、バインダの変更を保存した後でファイルマネージャを再起動したかどうか確認してください。ファイルマネージャをすでに再起動していた場合、バインダで変更内容を再検査してください。変更したエントリが、バインダの「保存 (Save)」ボタンでユーザデータベースに保存されたことを確認してください。また、表示されたファイルが、バインダで変更されたファイルのクラスに本当に分類されるものかどうかも確認してください。
ファイルマネージャが 3 種類の総称アイコン (フォルダ、アプリケーション、および文書) しか表示しない場合、ファイルマネージャはバインダのデータベースとの接続に失敗したことになります。問題の発生場所を示すエラーメッセージが表示されているかどうか、コンソールウィンドウを調べてください。
フロッピーディスクまたは CD のウィンドウを削除した場合、「フォルダ変更」メニューのボタンからこれらのウィンドウを選択して、再表示することができます。これらは、 「フォルダ変更」メニューのアプリケーション固有の部分に常に表示されています。 「フォルダ変更」メニューの使い方については、第 2 章「ファイルマネージャ」を参照してください。
ファイルマネージャを使って、ファイルを他のアプリケーションにドラッグ&ドロップし、ファイルマネージャのフッタにエラーメッセージ「ドラッグ&ドロップ: ターゲットが正しくありません。」が出力された場合、そのファイルは、ファイル形式を認識しない場所またはドロップ操作をサポートしない場所にドロップされたことになります。
ファイルの内枠に表示されるはずのファイルが表示されない場合、これらのファイルの表示を抑制できるファイルマネージャのプロパティウィンドウから表示フィルタパターンを指定していないことを確認してください。フィルタが指定されると、ファイルマネージャウィンドウのヘッダには常にフィルタが表示されます。この問題を解決するには、「表示」-> 「アイコン形式で名前順」を選択してみてください。
リモートシステム間でのファイル転送にトラブルがある場合、ユーザはファイル、ディレクトリ、またはシステムにアクセスするための適切なパーミッションを持っていない可能性があります。あるいは、そのリモートシステムはネットワークを通じてアクセスできない可能性があります。ファイルを所有する人 (または、ファイルの転送を依頼した人) に連絡して、転送が可能となるようにパーミッションを変更してください。リモートシステムがユーザのネットワークで使えるかどうかを判断するには、システム管理者に連絡してください。
ファイルマネージャが内容によるファイル表示を行っているとき、ファイルの最初の画面を表示できるよう、これを読み出して圧縮する必要があります。Sun アイコン、X Bitmap、および X Pixmap ファイルに関しては、圧縮作業はかなり高速に行われます。しかし、Sun の大きなラスタイメージの圧縮には少し時間が必要です。したがって、アイコンファイルだけを見れば十分な場合、「現在のフォルダ設定」と「新しいフォルダのデフォルト」のプロパティで、内容表示の設定は「モノクロアイコン」と「カラーアイコン」だけを選択します。
イメージツールを実行しようとして下記のメッセージを受け取った場合、XIL パッケージをインストールする必要があります。
ld.so.1: imagetool: can't find file libxil.so.1 killed |
システム管理者に確認してください。
複数バージョンのメールプログラムを実行する場合、メールツールはユーザの In-Box の状態について混乱することがあります。メールツールが In-Box のオープンに長時間を要する場合、メールツールのロックファイルを削除しなければならないことがあります。 「変更内容を保存」操作に十分なディスク容量がない場合、現在のメールファイルからメッセージを除去する必要があります。この節では、これらの問題の認識と訂正の方法について説明します。さらに、メールツールの In-Box を見つけるディレクトリや、メールツールまたはウィンドウシステムのクラッシュ時にクリアまたは失われた、作成中のメールメッセージを見つけるディレクトリについても説明します。
同時に複数バージョンのメールツール (またはメールツールアプリケーションとメールプログラム) を実行した場合、メールツールアプリケーションの 1 つを「変更内容を保存」または「終了」するように、メールツールアプリケーションから警告を受け取ることがあります。これは、両方のバージョンが In-Box を変更しようとしたためです。In-Box の状態についての混乱の発生を避けるには、警告指示に従ってください。
別のメールツールやメールプログラムを実行する前に、メールツールの「処理終了」または「変更内容を保存」を選択しなかった場合、メールツールを終了するように警告指示されます。変更内容を保存した場合、メールツールを「終了」するか、または 「変更内容を保存」を行なって元の状態を保つかを選択できます。
メールツールの終了を避けるには、毎日の終り、またはマシンにログインしてリモートからメールを読みそうなときに、「ファイル」メニューから 「処理終了」を選択する習慣をつけてください。
「処理終了」の選択を忘れ、メールを読むためにリモートからマシンにログインした場合、下記のステップに従うことによって、メールツールに 「処理終了」を選択するよう指示できます。
シェルツールのプロンプトから、 ps -e | grep mailtool と入力し、Return キーを押します。
図 A-2 に示すようなリストが出力されます。
(grep mailtool のリストではなく) mailtool の行の左側のカラムから、プロセス番号 (PID) を見つけます。
プロセス番号は各行の最初の数字です。
kill -USR1 PID と入力して、Return キーを押します。
上の例ではプロセス番号は 1431 であるため、次のように入力します。 kill -USR1 1431
いつものように、リモート位置からメールを読み取ります。
メールツールを次にオープンしたとき、リモート位置から In-Box に対して行なった変更内容が組み込まれ、メールツールの一部として記録されます。
上記のステップは、DeskSet のメールツールアプリケーションでのみ有効です。他のバージョンのメールツールにこれらのステップを使った場合、メールツールが停止します。
メールユーティリティではロックファイルを使って、複数のプロセスがユーザのメールスプールファイルを同時に変更することを防止します。メールツールが突然終了した場合、ロックファイルはそのまま残されます。
In-Box を明確に要求したときに、または「ファイル」メニューから 「処理終了」を選択した後でメールツールをオープンしたときに、メールツールによる In-Box のオープンに長時間を要する場合、ロックファイルを調べてください。ディレクトリ /var/mail に <ユーザ名>.lock という名前のファイルがないか探してください。ここでの <ユーザ名> はユーザのログイン名です。
このファイルを削除するには、システムプロンプトに続けて次のように入力します。
rm /var/mail/<ユーザ名>.lock. |
たとえば、<ユーザ名> が mary の場合、次のように入力します。
rm /var/mail/mary.lock. |
あるいは、ファイルマネージャ内のロックファイルを見つけ出して、これをごみ箱 にドラッグして削除します。
メールツールの In-Box のデフォルトの位置は /var/mail/<ユーザ名> です。環境変数 $MAIL が存在する場合、メールツールはこの値を In-Box の位置として使います。
メールツールアプリケーションまたはウィンドウシステムがクラッシュしたとき、メールメッセージが作成中であった場合、ホームディレクトリ内のファイル dead.letter から、メッセージのコピーを回復できます。ただし、80 個の編集情報ごとにアプリケーションがファイルに記録するため、最後の 80 個分の編集情報は失われることがあります。
作成ウィンドウの「クリア」ボタンの上でセレクトボタンをクリックするたびに、または作成ウィンドウの「送信」メニューから「メッセージのクリア」を選択するたびに、ユーザのメッセージはファイル dead.letter に保存されます。
dead.letter および保存変数の詳細については、mail のマニュアルページを参照してください。
「ファイル」メニューから 「変更内容を保存」や 「処理終了」を選択したり、あるいはメールフォルダを切り替えることによって変更内容を保存しようとしたりして、メールツールからディスク容量の尽きたことを警告された場合、現在のメールファイルからメッセージを除去して、保存できるサイズにまで小さくしなければなりません。
メッセージは、削除または移動によって除去できます。大きなメッセージを除去するのが最も効果的です。「表示」メニューの「表示順序」サブメニューから「サイズ」を選択することによって、最も大きなメッセージを見つけ出すことができます。
大きすぎるファイルをメールツールのアタッチメントウィンドウにドラッグ&ドロップした場合、メールツールがスワップ領域を使い果たすことがあります。この対策としては、スワップ領域を増大させることです。
バインダデータベース内にあるファイルのプリントスクリプトが不適切な場合 (このファイルは ASCII ファイルではなく、おそらく /usr/openwin/lib/cetables にある)、印刷ツールは、そのファイルをプリントしようとすると停止してしまいます。プリントスクリプトには $FILE、$PRINTER、または $COPIES 変数が存在しないことがあります。バインダを使ってプリントスクリプトを変更する方法については、第 16 章「バインダ」を参照してください。
ファイルをプリントし、そのプリンタでは適切なフィルタが利用できない場合、エラーメッセージが返されます。
スナップショットでの潜在的な問題点は、他のアプリケーションでは使えないようなサイズのラスタファイルを作成することです。以下でこの問題について説明します。
他のアプリケーションでスナップショットファイルを使うことが困難な場合があります。その原因は、グレースケールモニタまたはカラーモニタからのスナップショットを白黒画像しか扱えないアプリケーションに組み込もうとしたためです。
ラスタファイルには高さ、幅、および深さの 3 つのディメンションがあります。白黒のラスタファイルは深さ 1 ビットです。グレースケールおよびカラーのラスタファイルは、通常、深さ 8 ビットです。自然色のラスタファイルは深さ 24 ビットです。4 ビットの画面でスナップショットを取った場合、これは 8 ビットのラスタファイルとして保存されます。
ラスタファイルの深さは、シェルツールまたはコマンドツールのプロンプトで file <ラスタファイル名> と入力するか、またはファイルマネージャからファイルを選択して 情報ウィンドウを表示することによって調べられます。図 A-3 に示した例では、最後が .rs で終わるすべてのファイルのファイル特性が示されています。このリストには、8 ビットのラスタファイル (snapshot.rs) が 1 つあり、残りはすべて 1 ビットのファイルです。
ある画像を、ユーザのモニタと同じ深さに変換する最善の方法は、イメージツールを使うことです。スナップショットを取り、それを表示します。カラー項目から「モノクロ」を選択して、「保存」ボタンを押します。第 13 章「イメージツール」を参照してください。
この節では、テープツールに関して発生する共通の問題点、およびその可能な解決策について説明します。
tar テープからファイルを読み出しているときに checksum エラーを受け取った場合、テープ上のブロックサイズとユーザの指定したブロックサイズが一致していない可能性があります。
ブロックサイズを訂正するには、テープツールのプロパティウィンドウからブロック I/O を選択します。表示されるテキストフィールドで、(テープからの) 正しいブロックサイズを入力してください。
テープからファイルを取り出し、これらのファイルがユーザの指定する宛先ディレクトリにコピーされない場合、テープの内容をリストし、ファイル名の前に絶対パス名が付けられているかどうか確認します。絶対パス名を持つファイルを取り出したとき、そのパスは宛先ディレクトリとして使われます。
システムインストール時にテープ装置を接続していなければ、テープ装置名は自動的にシステム構成に取り込まれません。
最初のシステムインストールの後でテープ装置を追加したが、その後でシステムを再起動しなかった場合に、このエラーメッセージが表示されます。システムを再構成して新しいテープ装置名を組み込むには、システムをシャットダウンして次のようなフラグを使用して再起動して下さい。
OK プロンプトに対して次のように入力します。
boot -r |
boot> プロンプトに対して次のように入力します。
b -r |
エラーメッセージを受信したり、ここに挙げる問題が発生することがあります。この節では、この種の問題点に対する可能な解決策を説明します。
このエラーメッセージを受信した場合、OpenWindows がインストールされた場所を指し示すよう、OPENWINHOME が適切に設定されていることを確認する必要があります。環境の設定については、第 17 章「Solaris 環境のカスタマイズ」を参照してください。
OpenWindows は起動するが、アプリケーションの一部または全部が使えません。
この問題が発生した場合、/usr/openwin/bin が残りのパスエントリの前に置かれるように、パス設定が行われていることを確認する必要があります。
プロセスやアプリケーションが異常終了して、プロセスを開始したディレクトリ内に core という名前のファイルが残ることがあります。core ファイルは多くのディスク容量を必要とします。したがって、異常終了したプログラムに関する情報や、解析用の core ファイルの位置に関する情報をシステム管理者に提供し、解析が終了した後、削除することをお薦めします。
どのプロセスまたはアプリケーションが異常終了したのか明確ではない場合、シェルウィンドウをオープンして、システムプロンプトに続けて下記の内容を入力します (core.directory をユーザのディレクトリ名に置き換えてください)。
example% cd core.directory(ディレクトリを core ファイルの位置に変更 ) example% file core |
core ファイルの出所について知らせるメッセージを、そのシェルに受信します。この情報をシステム管理者に提供してください。
オペレーティングシステムの知識を持つ人は、独力で core ファイルを解析できます。基本的な 2 つのデバッギングツールに関連する情報が、adb および dbx のマニュアルページに掲載されています。
スクリーンセーブオプション (第 17 章「Solaris 環境のカスタマイズ」で説明) を設定し、画面がブランクになった場合、マウスを任意の方向に動かすことによってデスクトップを復元できます。どのキーボードキーやマウスボタンからの入力でも画面を復元できますが、マウスを使うことをお薦めします。これは、キーを押すことによってシステム入力が行われるため、たとえば、テキストファイル内にポインタが置かれている場合、そのテキストに文字を挿入してしまうことがあるためです。
別タイプの複数のアプリケーション (たとえば、SunView と OpenWindows のアプリケーション) を実行している場合、ユーザがウィンドウに入力した文字が乱れて表示されることがあります。
この問題を解決するには、ポインタをワークスペースのバックグラウンドに置き、 「ワークスペース」->「ユーティリティ」->「リセット入力」 を選択します。
この節は SPARC マシンだけに該当します。
ホームディレクトリ内に .xinitrc ファイルがあり、しかも OpenWindows のグローバルな資源設定に依存するアプリケーションに問題を抱えている場合、トラブル解決の 1 つの方法として、ファイルを .xinitrc.orig にリネームして OpenWindows を再起動することがあります。
これで問題が解決した場合、 (/usr/openwin/lib/Xinitrc にある) システムバージョンと .xinitrc 間の変化を吸収するか、あるいは、それ以上必要でなければ削除します。
オーバラップしたウィンドウがクリアされたとき、遺物 (あるいは他のウィンドウの残骸) がウィンドウ上に残されることがあります。これをウィンドウの破壊と呼びます。画面を再描画するには、「ワークスペース」->「ユーティリティ」->「再表示」を選択します。破壊はただちにクリアされます。
破壊が 1 つのアプリケーションウィンドウにだけ発生する場合、そのウィンドウのヘッダにあるポップアップメニューから「再表示」を選択することにより、そのアプリケーションウィンドウを再表示できます。
下記の例のように、シェルツールまたはコマンドツールウィンドウ内のコマンド行からアプリケーションをオープンした場合、ウィンドウが動かなくなることがあります。
example% cmdtool |
コマンド行で任意の DeskSet またはその他の XView アプリケーションをオープンする最善の方法は、コマンドにアンパサンド (&) を追加することです。たとえば、次のように指定します。
example% cmdtool & |
これによって、このアプリケーションはバックグラウンドで起動されるため、アプリケーションを起動した親ウィンドウはその後も自由に使えます。
ポインタを (テキストエディタやメールツールの作成サブウィンドウなどの) テキストウィンドウ内に置き、入力を開始しても、入力したテキストがウィンドウに表示されない場合、そのウィンドウはおそらく有効ではないので、ウィンドウ内でセレクトボタンをクリックして有効にしなければなりません。
なお、テキストウィンドウ内の挿入ポイントは、そのウィンドウが有効か無効かによって、見掛け上変化します。挿入ポイントが有効である場合、三角形のように表示されます。無効である場合、うす暗いダイヤモンドのように表示されます。有効な挿入ポイントと無効な挿入ポイントを図 A-4 に示します。
ワークスペースのプロパティを変更して、ユーザがそこへポインタを移動したときに、ウィンドウの入力領域が自動的に有効になるようにできます。これにより、ウィンドウ内でセレクトボタンをクリックするステップを回避できます。これはベースウィンドウ (つまり、アプリケーションのメインウィンドウ) で有効です。しかし場合によっては、メールツールの作成サブウィンドウのように、起動するためには必ずウィンドウ内でセレクトボタンをクリックしなければならないものもあります。詳細については、第 17 章「Solaris 環境のカスタマイズ」を参照してください。
ワークスペースのプロパティを使うときに経験する問題点もあります。
これは .xinitrc ファイルが古いためです。詳細については、「.xinitrc での問題点」を参照してください。
ウィンドウ・フォアグラウンド、データ領域のフォアグラウンドとバックグラウンドに変更を行った場合、XView がこれらのリソースに応答しないことがあります。
XView アプリケーションに関しては、$HOME/.Xdefaults 内の window.color.foreground と window.color.background を手動で設定してみてください。
カラーのプロパティからカラーマップの使用に関するメッセージを受け取り、プログラムを続行できない場合、カラーマップがいっぱいになっていることがあります。
カラーマップ資源を大量に使うアプリケーションを終了させ、プロパティを再起動し、再び実行してください。
すべてのフォントスケールを正しく処理していないプログラムがあります。
XView のアプリケーションはアイコンを制御しますが、ビットマップを使いません。
カラー設定の可用性は、ハードウェアに依存します。
C ロケールは 8 ビット文字 (たとえば、G1 セットまたは ISO 8859-1 文字セットの右側のもので、ここには文音記号などが含まれる) をサポートしていません。このような場合は、英語環境で en_US ロケールを使用して 8 ビット文字を表示してください。
en_US ロケールを指定するには、ワークスペースの「プロパティ」プルダウンメニューから、「ローカリゼーション」で en_US を選択してください。
もう一つの方法として、Bourne シェルを使用している場合は、‾/.profile ファイルに次の行を追加することにより en_US ロケールを指定できます。
LANG=en_US; export LANG |
また C シェルを使用している場合は、次の行を ‾/.login ファイルに追加することにより en_US を指定できます。
setenv LANG en_US |