この章では,プリント・システムで検出される可能性のある一般的な問題のいくつかを説明するとともに,問題を修正するための対処方法について説明します。
12.1 サーバ問題の解決
この節では,通常のプリント・システム処理で起こる可能性のあるサーバ・エラーについて説明します。これらのエラーはサーバ・エラーとして記述されますが,必ずしもスプーラやスーパバイザのオブジェクトだけが原因のエラーではなく,プリント・システムの他のオブジェクトが原因の場合もあります。
12.1.1 どのサーバ・プロセスが実行中であるかを調べる
スーパバイザまたはスプーラ・プロセスがクライアント要求に応答しない場合,次のコマンドを使用して,どのサーバ・プロセスが実行中であるかを判断できます。
# ps -ef | grep pd
pdsplr,pdspvr,pdspvlpr に対するプロセス・エントリが表示されない場合,正しいホストを見ているかどうかを確認してください。なくなっているサーバ・プロセスを再起動するには,次のコマンドの 1 つを使用してください。
# /usr/pd/lib/pdsplr # /usr/pd/lib/pdspvr # /usr/pd/lib/pdspvlpr
スーパバイザまたはスプーラのプロセスが実行中であっても,クライアントからの要求に応答しない場合は,pdls コマンドを使用してオブジェクトの状態を調べることができます。
# pdls -c server -r all s line server_name
サーバから応答がない場合,プロトサーバ・デーモンが実行中であるかどうかを確認してください。
# pcinfo -u 105004
プロトサーバが実行中の場合,次のように表示されます。
# program 105004 version 1 ready and waiting
前述の手順を使用してどのコンポーネントが実行中であるのかと,それらのうちのどれが
rpcinfo -u
コマンドまたは
-t
コマンドに応答するのかを調べてください。プロトサーバが応答しない場合は,次の手順を使用してプリント・システムを再起動してください。
すべての
pdspvr
,pdsplr
,pdspvlpr
プロセスについて kill -9 を実行します。
フォーム
/var/pd/pts/.pts*
のすべてのファイルを消去します。
inetd
プログラムの PID を調べて,それに "hangup" 信号を送信します。
# ps ax | grep inetd 462 ?? I 0:16.91 /usr/sbin/inetd ttyp7 S + 0:00.02 grep inetd # kill -1 462
もう一度プロトサーバ・デーモンと通信してみます。
# rpcinfo -u host 105004
プリント・システム・スプーラ (pdsplr) を再起動し,今は通信できるかどうかをチェックします。
# /usr/pd/lib/pdsplr servername # pdls -c server servername
スプーラが応答する場合は,他のサーバを同様に再起動してください。
pdshutdown コマンドが,スーパバイザ・サーバの停止に完全に有効ではない場合があります。そのような場合は,スーパバイザ・サーバが終了するまで少なくとも 2 分間待ってください。物理プリンタが printing (印刷中) 状態でないことを検証することによって,サーバがプリンタに対してジョブを実際には印刷していないことを確認してください。プリンタに一時停止されたジョブがあるかどうかを確認してください。
スーパバイザは,pdshutdown コマンドで
-w now
を指定しない限り,ジョブが一時停止されている場合にはシャットダウンしません。次に,スーパバイザの PID を調べ,"kill -9" を使用してそれを終了させてください。
# pdls -c printer servername: printer-name printer-realization printer-state enabled ------------ ------------------- ------------- ------- LN17ps_PP physical idle yes LGP physical idle no Richs_PP physical idle no Sharie_PP physical idle no LN03R physical idle no ln17bert physical idle no lps17_sue physical idle no Null_PP physical idle no # ps ax | grep pds 29874 ?? I 0:00.64 /usr/pd/lib/pdsplr merle_spl 30481 ?? S 0:34.69 /usr/pd/lib/pdspvr merle_sup 5008 ttyp7 S + 0:00.02 grep pds # kill -9 30481
前述の「スーパバイザがシャットダウンしない」と同じ手順を使用してスプーラ・プロセスを停止させます。
12.2 ジョブとプリントの問題
この節では,通常のプリント・システムの処理中に起こる可能性のあるジョブとプリントのエラーを説明します。これらのエラーはジョブやプリントのエラーとして記述されていますが,これは必ずしもプリントやジョブのオブジェクトだけが原因のエラーではなく,プリント・システムの他のオブジェクトが原因である可能性もあります。
12.2.1 PostScript ドキュメントで PostScript プログラム・コードが印刷される
PostScript コードを生成するアプリケーションの中には,PostScript のリードイン・シーケンス "%!" を誤って取り除くものがあります。ドキュメントが "%!" で始まらない場合,プリント・システムのスーパバイザはそのファイルをテキスト・ファイルであると誤って判断し,それをプリンタに解釈させずに,テキスト・リストに翻訳します。
ジョブを再実行して,document-format を PostScript と指定します。
12.2.2 物理プリンタが接続状態でハングする
ジョブが割り当てられるときに,出力デバイスがアクセスできない場合,物理プリンタ・オブジェクトは "connecting-to-printer (プリンタに接続中)" 状態のままになります。これが起こるのには,次のような複数の理由があります。
プリンタが他のジョブの印刷でビジー状態である。
プリンタがオフラインである。
プリンタの電源が入っていない。
プリンタへのネットワーク・パスにアクセスできない。
プリンタは双方向セッション・コントロール (printer-connection-level=4
) 用に構成されているが,デバイスがこのレベルをサポートできない
プリンタ・オブジェクトを "idle (アイドル)" に戻す唯一の方法は,ジョブを消去 (取消し) することです。
12.2.3 処理待ち状態のままのジョブ
次の手順を使用して,ジョブが実行された後に処理待ち状態のままになる理由を調べてください。
物理プリンタが使用可能になっており,その状態がアイドルであることを確認します。
ジョブを実行したときに明示的に指定された,あるいは初期値オブジェクトによって暗黙に指定された,すべてのジョブとドキュメントの要件が,キューに関連付けられている少なくとも 1 つの物理プリンタ上で,両方とも "supported" および "ready" であることを確認します。
たとえば,初期値オブジェクトで
job-sheets
,document-sheets
,両面印刷,N アップ (片面に複数ページ印刷) などを指定している論理プリンタに対してジョブを実行した場合,対応する xxx-supported 属性と xxx-ready 属性が物理プリンタに設定されていることをチェックしてください。
これを行うには,次のコマンドを使用します。
# pdls -c p -r job-sheets-ready pp_name # pdls -c p -r document-sheets-ready pp_name # pdls -c p -r plexes-supported pp_name # pdls -c p -r numbers-up-supported pp_name
この節では,プリンタやサーバのオブジェクト以外のプリント・システムのサブシステムに関連するエラーとその解決方法について説明します。さらに,この節ではエラー情報がシステム内のどこにあるのかという情報も説明します。
12.3.1 コンソール通知が働かない
コンソールに通知メッセージが表示されない場合,あるいは,メール通知メッセージが送信されていない場合は,コンソール通知デーモン
pdconntf
が実行中かどうかを,次の手順を実行することによって確認してください。
ps
コマンドを使用して,デーモンが実行中であるかどうかを調べます。
# ps aux | grep pdconntf
実行されていない場合は,端末ウィンドウで次のように実行してください。
# /usr/pd/lib/pdconntf
ほとんどすべてのエラーについて,ユーザ・コンソールに書き込まれたクライアント・メッセージには,利用可能なすべてのエラー情報が含まれています。場合によっては,特に,ネットワーク,メモリの利用可能度,プロセス・スロットなどのシステム・リソースに関連する問題の場合は,追加のエラー情報がシステム・ログに書き込まれます。プリント・システムのクライアントとサーバは,特定のタイプのシステム・エラーが起こると,システム・ログにメッセージを書き込みます。Tru64 UNIX システムでは,システム・ログは
/var/adm/syslog.dated/
にあります。サーバはメッセージを
lpr.log
に書き込み,クライアントはメッセージを
user.log
に,ときには
lpr.log
に書き込みます。プリント・システム・プログラムがメッセージを
daemon.log
に書き込むこともあります。
コマンドの構文が正しく,オプション値がすべて正しいことを確認した後で,意味不明なコマンド・エラーを検出した場合は,システム・ログにさらに情報があるかどうかを確認してください。