パート VII Solaris ソフトウェアで発生する問題の解決

このパートでは、Solaris ソフトウェアで発生する問題を解決する手順を説明します。次の章が含まれます。

第 30 章 ソフトウェアの問題解決の概要

この章では、ソフトウェアの問題の解決についての概要を説明します。システムクラッシュの問題の解決とシステムメッセージの表示などが含まれます。

この章の内容は次のとおりです。

• 「ソフトウェアの問題の解決方法の参照先」

• 「システムクラッシュの問題の解決」

• 「システムクラッシュを解決するためのチェックリスト」

• 「システムのメッセージの表示」

• 「システムのメッセージ記録のカスタマイズ」

ソフトウェアの問題の解決方法の参照先

ソフトウェアの問題の解決手順については、次の章を参照してください。

• 第 31 章「システムクラッシュ情報の生成と保存」

• 第 32 章「ソフトウェアで発生するさまざまな問題の解決」

• 第 33 章「ファイルアクセスでの問題の解決」

• 第 34 章「印刷時の問題の解決」

• 第 35 章「ファイルシステムで発生する問題の解決」

• 第 36 章「ソフトウェア管理の問題の解決」

システムクラッシュの問題の解決

Solaris オペレーティング環境が動作しているシステムがクラッシュした場合は、クラッシュダンプファイルを含む、可能なかぎりの情報を購入先に提供してください。

システムがクラッシュした場合の対処方法

最も重要なことは、次のとおりです。

1. システムのコンソールメッセージを書き取ります。

   システムがクラッシュした場合は、システムをリブートする前に、まずコンソール画面にメッセージが表示されていないか確認してください。このようなメッセージは、クラッシュした原因を解明するのに役立ちます。システムが自動的にリブートして、コンソールメッセージが画面から消えた場合でも、システムエラーログファイルを表示すれば、これらのメッセージをチェックできます。システムエラーログファイルは、/var/adm/messages (または /usr/adm/messages) に自動的に生成されます。システムエラーログファイルを表示する方法の詳細は、「システムメッセージを表示する方法」を参照してください。

   クラッシュが頻繁に発生して、その原因を特定できない場合は、システムのコンソールや /var/adm/messages ファイルから得られるすべての情報を収集して、購入先に問い合わせください。購入先に問い合わせるときに必要な問題解決のための情報の完全なリストについては、「システムクラッシュの問題の解決」を参照してください。

   システムのクラッシュ後にリブートが失敗する場合は、第 32 章「ソフトウェアで発生するさまざまな問題の解決」を参照してください。

2. 次のように入力してディスクとの同期をとり、リブートします。

   ok sync
   

   システムのクラッシュ後にリブートが失敗する場合は、第 32 章「ソフトウェアで発生するさまざまな問題の解決」を参照してください。

3. savecore コマンドを実行して、スワップ領域に書き込まれたクラッシュ情報を保存します。

   # savecore
   

クラッシュダンプを自動的に保存する方法については、第 31 章「システムクラッシュ情報の生成と保存」を参照してください。

問題の解決に使用するデータの収集

システムの問題を特定するために、次の質問に答えてください。クラッシュしたシステムの問題を解決するためのデータを収集するには、「システムクラッシュを解決するためのチェックリスト」を参照してください。

システムクラッシュを解決するためのチェックリスト

クラッシュしたシステムの問題を解決するためのデータを収集するときは、次のチェックリストを使用します。

システムのメッセージの表示

システムがクラッシュしたとき、次のようなメッセージがシステムのコンソールに表示されることがあります。

panic: error message

error message は、crash(1M) のマニュアルページに説明されているパニックエラーメッセージの 1 つです。

さらに頻繁ではありませんが、パニックメッセージではなく、次のメッセージが表示されることがあります。

Watchdog reset !

エラー記録デーモン syslogd は、自動的に様々なシステムの警告やエラーをメッセージファイルに記録します。デフォルトでは、これらのシステムメッセージの多くは、システムコンソールに表示されて、/var/adm (または /usr/adm) に格納されます。システム記録を設定することによって、これらのメッセージを格納する場所を指示できます。詳細は、「システムのメッセージ記録をカスタマイズする方法」を参照してください。これらのメッセージは、失敗の予兆のあるデバイスなど、システム障害をユーザーに警告できます。

/var/adm ディレクトリには、いくつかのメッセージファイルが含まれています。最も新しいメッセージは、/var/adm/messages (および messages.0) にあり、最も古いメッセージは、messages.3 にあります。一定の期間 (通常は 10 日) ごとに、新しい messages ファイルが作成されます。messages.0 のファイル名は messages.1 に、messages.1 は messages.2 に、messages.2 は messages.3 にそれぞれ変更されます。その時点の /var/adm/messages.3 は削除されます。

/var/adm ディレクトリは、メッセージやクラッシュダンプなどのデータを含んでいる大きなファイルを格納するため、多くのディスク容量を消費します。/var/adm ディレクトリが大きくならないようにするために、そして将来のクラッシュダンプが保存できるようにするために、不要なファイルを定期的に削除しなければなりません。crontab を使用すれば、この作業は自動化できます。この作業を自動化する方法については、「クラッシュダンプファイルを削除する方法」と第 21 章「システムイベントのスケジュール設定」を参照してください。

システムメッセージを表示する方法

システムクラッシュまたはリブートによって生成された最近のメッセージを表示するには、dmesg コマンドを使用します。

$ dmesg

あるいは、more コマンドを使用して、メッセージを 1 画面ごとに表示します。

$ more /var/adm/messages

詳細は、dmesg(1M) のマニュアルページを参照してください。

例 - システムメッセージを表示する

次の例は、dmesg コマンドからの出力を示しています。

$ dmesg
SunOS Release 5.7 Version Generic [UNIX(R) System V Release 4.0]
Copyright (c) 1983-1998, Sun Microsystems, Inc.
vac: enabled in write through mode
cpu0: FMI,MB86904 (mid 0 impl 0x0 ver 0x4 clock 110 MHz)
mem = 57344K (0x3800000)
avail mem = 53268480
Ethernet address = 8:0:20:7c:d8:60
root nexus = SUNW,SPARCstation-5
iommu0 at root: obio 0x10000000
sbus0 at iommu0: obio 0x10001000
espdma0 at sbus0: SBus slot 5 0x8400000
espdma0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000
esp0:	esp-options=0x46
esp0 at espdma0: SBus slot 5 0x8800000 sparc ipl 4
esp0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000
sd3 at esp0: target 3 lun 0
sd3 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/...
	root on /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/...
obio0 at root
          .
          .
          .

システムのメッセージ記録のカスタマイズ

/etc/syslog.conf ファイルを変更すると、様々なシステムプロセスが生成するエラーメッセージを記録できます。デフォルトでは、/etc/syslog.conf は、多くのシステムプロセスのメッセージが /var/adm メッセージファイルに格納されるように指示しています。クラッシュとブートのメッセージも、同様にこのファイルに格納されます。/var/adm メッセージを表示する方法については、「システムメッセージを表示する方法」を参照してください。

/etc/syslog.conf ファイルは、タブで区切られた 2 つの列から構成されています。

facility.level ...

action

facility.level

action

次は、デフォルトの /etc/syslog.conf ファイルの例です。

user.err					/dev/console
user.err					        /var/adm/messages
user.alert					     `root, operator'
user.emerg					     *

最も一般的なエラー状態の出所を表 30-2 に示します。最も一般的な優先順位を、重要度順に表 30-3 に示します。

Solaris 2.6 リリース以降、/etc/syslog.conf ファイルで有効化できる syslog 機能の数の制限は解除されます。以前のリリースでは、機能の数は 20 個に制限されていました。

システムのメッセージ記録をカスタマイズする方法

1. スーパーユーザーになります。

2. 任意のエディタで、/etc/syslog.conf ファイルを編集します。syslog.conf(4) のマニュアルページで説明している構文に従って、メッセージの出所、優先順位、およびメッセージの記録場所を追加または変更します。

3. 変更を保存して編集を終了します。

例 - システムのメッセージ記録をカスタマイズする

次の /etc/syslog.conf 行は、Solaris インストール中にデフォルトで提供されます。

user.err					/dev/console
user.err					        /var/adm/messages
user.alert					     `root, operator'
user.emerg					     *

これは、次のユーザーメッセージが自動的に記録されることを意味します。

• ユーザーエラーは、コンソールに出力されて、/var/adm/messages ファイルにも記録されます。

• 早急な処置が必要なユーザーメッセージ (alert) は、root と operator に送信されます。

• ユーザー緊急メッセージは、各ユーザーに送信されます。

第 31 章 システムクラッシュ情報の生成と保存

この節では、クラッシュダンプを有効または無効にする方法と、システムメッセージを表示または収集する方法について説明します。

この章で説明する手順は次のとおりです。

• 「現在のクラッシュダンプ構成を表示する方法」

• 「クラッシュダンプ構成を変更する方法」

• 「クラッシュダンプを検査する方法」

• 「フルクラッシュダンプディレクトリから復元する方法 (省略可能)」

• 「クラッシュダンプの保存を有効または無効にする方法」

システムクラッシュ情報の管理に関する新機能

この節では、Solaris 7 リリースで使用可能になった新しいシステムクラッシュダンプ機能は次のとおりです。

新しいシステムクラッシュダンプ機能

Solaris 7 のシステムクラッシュダンプ機能は、次のとおりです。

• 新しい dumpadm コマンドを使用すると、システム管理者はオペレーティングシステムのクラッシュダンプを構成できます。dumpadm 構成パラメタでは、ダンプ内容、ダンプデバイス、クラッシュダンプが保存されるディレクトリなどを指定します。dumpadm コマンドの詳細は、「dumpadm コマンド」を参照してください。

• ダンプデータは、圧縮した形式でダンプデバイスに格納されます。カーネルのクラッシュダンプイメージは 4G バイトを超える場合があります。データを圧縮することにより、ダンプが速くなり、ダンプデバイスのディスク領域も少なくてすみます。

• 専用のダンプデバイス（1 次スワップ領域ではなく）がダンプ構成の一部にあると、クラッシュダンプファイルの保存はバックグラウンドで行われます。つまり、ブートシステムは、savecore コマンドが完了するのを待たなくても、次の手順に進むことができます。大容量のメモリーを搭載したシステムでは、savecore コマンドが完了する前にシステムが使用可能になります。

• savecore コマンドで生成されるシステムクラッシュダンプファイルは、デフォルトで保存されます。

• savecore -L コマンドは、移動中の Solaris オペレーティング環境でクラッシュダンプを取得できる新しい機能です。たとえば、性能に問題が発生しているときやサービスが停止しているときなどにメモリーのスナップショットをとって、実行中のシステムの問題を解決するのに使用します。システムが実行中で、一部のコマンドがまだ使用できる場合は、savecore -L を使用してシステムのスナップショットをダンプデバイスに保存し、クラッシュダンプファイルをただちに savecore ディレクトリに書き込むことができます。システムが実行中であるため、専用のダンプデバイスを構成してあれば、savecore -L を使用するだけでダンプを作成できます。

dumpadm コマンド

/usr/sbin/dumpadm コマンドは、システムのクラッシュダンプ構成パラメタを管理するコマンドです。次の表で dumpadm の構成パラメタを説明します。

詳細は、dumpadm(1M) のマニュアルページを参照してください。

dumpadm コマンドで管理するダンプ構成パラメタは、/etc/dumpadm.conf ファイルに保存されます。

/etc/dumpadm.conf は、手作業で編集しないでください。システムダンプ構成の整合性が失われる恐れがあります。

dumpadm コマンドの動作

dumpadm コマンドは、システム起動時に /etc/init.d/savecore スクリプトによって呼び出され、/etc/dumpadm.conf ファイルの情報に基づいてクラッシュダンプパラメタの構成を行います。

このコマンドは、/dev/dump インタフェースを通してダンプデバイスとダンプ内容を初期化します。

ダンプ構成が完了すると、savecore スクリプトは、/etc/dumpadm.conf ファイルの内容を解析してクラッシュダンプファイルのディレクトリの場所を探します。次に savecore を呼び出してクラッシュダンプがあるかどうかを調べます。さらに、クラッシュダンプディレクトリにある minfree ファイルの内容も調べます。

システムクラッシュ

システムクラッシュは、ハードウェアの誤動作、入出力の障害、ソフトウェアエラーなどが原因で発生します。システムがクラッシュすると、コンソールにエラーメッセージが表示され、物理メモリーの内容がダンプデバイスに書き込まれます。その後、システムは自動的にリブートします。システムがリブートすると、savecore コマンドが実行され、ダンプデバイスからデータを取り出し、保存されているクラッシュダンプを savecore ディレクトリに書き込みます。このクラッシュダンプファイルには、問題を診断する際にサポートプロバイダにとって大変役立つ情報が含まれています。

クラッシュダンプファイル

savecore コマンドはシステムクラッシュの後で自動的に起動され、ダンプデバイスからクラッシュダンプ情報を取り出して、unix.X と vmcore.X という 1 組のファイルを作成します。X はダンプシーケンス番号です。これらのファイルには、保存されたシステムクラッシュダンプの情報が含まれます。クラッシュダンプファイルは core ファイルと混同されることがありますが、コアファイルは、アプリケーションが異常終了した場合に書き込まれるユーザーアプリケーションのイメージです。

クラッシュダンプファイルは、あらかじめ指定されているディレクトリに保存されます。デフォルトでは /var/crash/hostname です。Solaris 2.6 リリースおよび互換バージョンでは、システムが、物理メモリーのイメージをクラッシュダンプファイルに保存できるように手作業で設定されていなければ、クラッシュダンプファイルは、システムがリブートしたときに上書きされてしまいました。Solaris 7 リリースでは、デフォルトでクラッシュダンプファイルが保存されます。

クラッシュダンプの保存

制御構造体、アクティブなテーブル、動作中またはクラッシュしたシステムカーネルのメモリーのイメージなど、カーネルの動作状況についての情報を調べるには、crash または adb ユーティリティを使用します。crash または adb を完全に使いこなすには、カーネルについての詳細な知識が必要ですが、このマニュアルでは説明を省きます。crash ユーティリティの詳細は、crash(1M) または adb(1) のマニュアルページを参照してください。

savecore で保存したクラッシュダンプを購入先に送って、システムがクラッシュした原因を解析してもらうことも可能です。購入先にクラッシュダンプファイルを送る場合は、「クラッシュダンプの管理」にリストされている最初の 2 つの作業を実行してください。

クラッシュダンプの管理

現在のクラッシュダンプ構成を表示する方法

1. スーパーユーザーになります。

2. dumpadm コマンドをオプションなしで実行し、現在のクラッシュダンプ構成を表示します。

   # dumpadm
         Dump content: kernel pages
          Dump device: /dev/dsk/c0t3d0s1 (swap)
   Savecore directory: /var/pluto
     Savecore enabled: yes

   上記の出力の意味は次のとおりです。

   • ダンプの内容は、カーネルメモリーページである

   • カーネルメモリーがスワップデバイス /dev/dsk/c0t3d0s1 にダンプされる。swap -l コマンドにより、すべてのスワップ領域を識別できる

   • コアファイルは /var/crash/venus ディレクトリに保存される

   • コアファイルの保存は有効に設定されている

クラッシュダンプ構成を変更する方法

1. スーパーユーザーになります。

2. dumpadmコマンドで、現在のクラッシュダンプ構成を確認します。

   # dumpadm
         Dump content: kernel pages
          Dump device: /dev/dsk/c0t3d0s1 (swap)
   Savecore directory: /var/crash/pluto
     Savecore enabled: yes

   上記の構成は、Solaris 7 リリースを実行するシステムのデフォルトダンプ構成です。

3. dumpadm コマンドでクラッシュダンプ構成を変更します。

   # dumpadm -c content -d dump-device -m nnnk | nnnm | nnn% -n -s savecore-dir
   

   -c content	ダンプするデータの種類、つまり、カーネルメモリーまたはすべてのメモリーのいずれかを指定する。デフォルトはカーネルメモリー
   -d dump-device	システムがクラッシュしたときに、ダンプデータを一時的に保存するデバイスを指定する。デフォルトのダンプデバイスは 1 次スワップデバイス
   -m nnnk | nnnm | nnn%	現在の savecore ディレクトリに minfree ファイルを作成することにより、コアファイルを保存する最小限の空き容量を指定する。このパラメタは K バイト (nnnk)、M バイト (nnnm)、またはファイルシステムサイズのパーセント (nnn%) で指定できる。savecore コマンドは、クラッシュダンプファイルを書き込む前にこのファイルを調べる。クラッシュダンプファイルを書き込むと空き容量が minfree の値より少なくなる場合、ダンプファイルは書き込まれず、エラーメッセージが記録される。このような問題を解決するには、「フルクラッシュダンプディレクトリから復元する方法 (省略可能)」を参照
   -n	システムがリブートするときに、savecore を実行しないように指定する。このダンプ構成は推奨できない。システムクラッシュ情報がスワップデバイスに書き込まれているときに、savecore が実行されないと、クラッシュダンプ情報はシステムがスワップを開始すると上書きされる
   -s	クラッシュダンプファイルを保存する別のディレクトリを指定する。デフォルトのディレクトリは /var/crash/hostname で、hostname は uname -n コマンドの出力

例 -クラッシュダンプ構成を変更する

次の例は、すべてのメモリーを専用のダンプデバイス /dev/dsk/c0t1d0s1 にダンプします。また、クラッシュダンプファイルを保存した後に残っていなければならない最小空き容量は、ファイルシステム容量の 10% です。

# dumpadm
      Dump content: kernel pages
       Dump device: /dev/dsk/c0t3d0s1 (swap)
Savecore directory: /var/crash/pluto
  Savecore enabled: yes
 # dumpadm -c all -d /dev/dsk/c0t1d0s1 -m 10%
      Dump content: all pages
       Dump device: /dev/dsk/c0t1d0s1 (dedicated)
Savecore directory: /var/crash/pluto (minfree = 77071KB)
  Savecore enabled: yes

クラッシュダンプを検査する方法

1. スーパーユーザーになります。

2. crash ユーティリティを使用して、クラッシュダンプを検査します。

   # /usr/sbin/crash [-d crashdump-file] [-n name-list] [-w output-file]

   -d crashdump-file	システムのメモリーイメージを格納するファイルを指定する。デフォルトのクラッシュダンプファイルは /dev/mem
   -n name-list	システムのメモリーイメージへのシンボリックアクセスを調べる場合、シンボルテーブル情報を格納するテキストファイルを指定する。デフォルトのファイル名は /dev/ksyms
   -w output-file	クラッシュセッションからの出力を格納するファイルを指定する。デフォルトは標準出力

3. クラッシュ状態情報を表示します。

   # /usr/sbin/crash
   dumpfile = /dev/mem, namelist = /dev/ksyms, outfile = stdout
   > status
      .
      .
      .
   > size buf proc queue
      .
      .
      .

例 - クラッシュダンプを検査する

次の例は、crash ユーティリティからのサンプル出力を示します。状態とバッファについての情報、プロセス、および待ち行列のサイズが表示されます。

# /usr/sbin/crash
dumpfile = /dev/mem, namelist = /dev/ksyms, outfile = stdout
> status
system name:    SunOS
release:        5.7
node name:      saturn
version:        Generic
machine name:   sun4m
time of crash:  Thu Feb 26 12:17:04 1998
age of system:  19 day, 23 hr., 55 min.
panicstr:
panic registers:
        pc: 0     sp: 0
> size buf proc queue
120
1552
88

フルクラッシュダンプディレクトリから復元する方法 (省略可能)

ここでは、システムがクラッシュしてもメモリーイメージを格納する十分な空き容量が savecore ディレクトリにないが、それでも、一部の重要なシステムクラッシュダンプ情報を保存するものとします。

1. システムがリブートした後で、スーパーユーザーとしてログインします。

2. すでにサービスプロバイダに送ってある既存のクラッシュダンプファイルを削除して、savecore ディレクトリ (通常は /var/crash/hostname) を整理します。あるいは、savecore コマンドを実行し、十分な容量を持つ別のディレクトリを指定します (次の手順を参照してください)。

3. 手作業で savecore コマンドを実行し、必要なら別の savecore ディレクトリを指定します。

   # savecore [ directory ]

クラッシュダンプの保存を有効または無効にする方法

1. スーパーユーザーになります。

2. dumpadm コマンドにより、システム上にクラッシュダンプを保存するかどうかを指定します。

例 - クラッシュダンプの保存を無効にする

次の例は、システムでのクラッシュダンプの保存を無効にします。

# dumpadm -n
      Dump content: all pages
       Dump device: /dev/dsk/c0t1d0s1 (dedicated)
Savecore directory: /var/crash/pluto (minfree = 77071KB)
  Savecore enabled: no
 

例 - クラッシュダンプの保存を有効にする

次の例は、システムでのクラッシュダンプの保存を有効にします。

# dumpadm -y
      Dump content: all pages
       Dump device: /dev/dsk/c0t1d0s1 (dedicated)
Savecore directory: /var/crash/pluto (minfree = 77071KB)
  Savecore enabled: yes

第 32 章 ソフトウェアで発生するさまざまな問題の解決

この章では、ときどき発生するが修正しやすい、さまざまなソフトウェアの問題について説明します。特定のソフトウェアアプリケーションや内容に関連しない問題 (リブートの失敗やファイルシステムがフルになるなど) の解決方法も含みます。これらの問題の解決方法は、この後の節で説明します。

この章の内容は次のとおりです。

• 「リブートが失敗した場合の対処方法」

• 「システムがハングした場合の対処方法」

• 「ファイルシステムがフルになった場合の対処方法」

• 「コピーまたは復元後にファイルの ACL が消失した場合の対処方法」

• 「バックアップ時の問題の解決」

リブートが失敗した場合の対処方法

システムがリブートに失敗した場合またはリブートしたがクラッシュした場合は、システムのブートを妨害しているソフトウェアまたはハードウェアの障害があると考えられます。

上記のリストで問題が解決できない場合は、ご購入先にお問い合わせください。

システムがハングした場合の対処方法

ソフトウェアプロセスに問題がある場合、システムは完全にクラッシュせずに凍結、つまりハングすることがあります。ハングしたシステムから回復するには、次の手順に従ってください。

1. システムがウィンドウ環境を実行していたかどうかを調べて、次のリストの推奨事項に従ってください。これらのリストで問題が解決できなかった場合は、手順 2 に進みます。

   • コマンドを入力しているウィンドウの中に、ポインタがあることを確認します。

   • 間違って Control-s キー (画面を凍結する) を押した場合は、Control-q キーを押します。Control-s キーはウィンドウだけを凍結し、画面全体は凍結しません。ウィンドウが凍結している場合は、他のウィンドウを試します。

   • 可能であれば、ネットワーク上の他のシステムからリモートでログインします。pgrep コマンドを使用して、ハングしているプロセスを見つけます。ウィンドウシステムがハングしている場合は、そのプロセスを特定して強制終了します。

2. Control-¥ キーを押して、動作しているプログラムを強制終了します。core ファイルが書き出されることがあります。

3. Control-c キーを押して、動作している可能性があるプログラムに割り込みをかけます。

4. リモートからログインして、システムをハングさせているプロセスを特定して強制終了します。

5. リモートからログインしてスーパーユーザーになり、システムをリブートします。

6. システムがまだ応答しない場合は、強制的にクラッシュダンプしてリブートします。強制的にクラッシュダンプしてリブートする方法については、第 31 章「システムクラッシュ情報の生成と保存」を参照してください。

7. システムがまだ応答しない場合は、電源を切ってから数分待ち、もう一度電源を入れます。

8. システムがまったく応答しない場合は、ご購入先にお問い合わせください。

ファイルシステムがフルになった場合の対処方法

ルート (/) ファイルシステムや他のファイルシステムがフルになると、次のようなメッセージがコンソールウィンドウに表示されます。

.... file system full

ファイルシステムがフルになる原因はいくつかあります。次の節では、フルになったファイルシステムを回復する方法をいくつか説明します。ファイルシステムがフルにならないように、古い使用されていないファイルを日常的に整理する方法については、第 19 章「ディスク使用の管理」を参照してください。

大規模ファイルまたはディレクトリを作成したために、ファイルシステムがフルになる

システムのメモリーが不足したために、tmpfs ファイルシステムがフルになる

コピーまたは復元後にファイルの ACL が消失した場合の対処方法

バックアップ時の問題の解決

この節では、データをバックアップまたは復元するときのいくつかの基本的な問題の解決方法について説明します。

ファイルシステムのバックアップ中に、ルート (/) ファイルシステムがフルになる

ファイルシステムをバックアップしている際に、ルート (/) ファイルシステムがフルになります。このとき、媒体には何も書き込まれていなく、ufsdump コマンドは、媒体の 2 番目のボリュームを挿入するようにプロンプトを表示します。

バックアップコマンドと復元コマンドが対応していることを確認する

ufsrestore を使用できるのは、ufsdump でバックアップしたファイルを復元するときだけです。tar でバックアップした場合は、tar で復元します。他のコマンドで書き込まれたテープを ufsrestore コマンドを使用して復元しようとした場合、テープが ufsdump フォーマットでないことを知らせるエラーメッセージが表示されます。

現在のディレクトリが間違っていないことを確認する

ファイルを復元する場合に、間違った場所に復元してしまうことがよくあります。ufsdump コマンドは、常にファイルシステムのルートからのフルパス名でファイルをコピーします。したがって ufsrestore を実行する前に、ファイルシステムのルートディレクトリに移動しなければなりません。それよりも下のディレクトリでファイルを復元すると、そのディレクトリの下に完全なファイルツリーが作成されます。

古い restore コマンドを使用して、複数ボリュームのフロッピーディスクのバックアップを復元する

dump コマンドで作成した複数ボリュームのフロッピーディスクのバックアップセットからファイルを復元するには、ufsrestore コマンドは使用できません。このようなファイルは、SunOS 4.1 システムで復元しなければなりません。

対話型コマンド

対話型コマンドを使用すると、次の例のような ufsrestore> プロンプトが表示されます。

# ufsrestore ivf /dev/rmt/0
Verify volume and initialize maps
Media block size is 126
Dump   date: Tue Jun 16 10:19:36 1998
Dumped from: the epoch
Level 0 dump of / on mars:/dev/dsk/c0t3d0s0
Label: none
Extract directories from tape
Initialize symbol table.
ufsrestore > 

ufsrestore> プロンプトでは、『Solaris のシステム管理 (第 1 巻)』の「ufsdump コマンドと ufsrestore コマンドの参照情報」にリストされているコマンドを使用して、ファイルの検索や、復元するファイルのリストを作成でき、ファイルを復元することもできます。

第 33 章 ファイルアクセスでの問題の解決

この章で説明する手順は次のとおりです。

• 「検索パスに関連する問題を解決する (コマンドが見つかりません)」

• 「ファイルアクセスの問題を解決する」

• 「ネットワークアクセスで発生する問題の把握」

以前は使用できていたプログラム、ファイル、またはディレクトリにアクセスできなくなる (システム管理者に問い合わせる) 場合があります。このようなときは、次の 3 点を調べてください。

• ユーザーの検索パスが変更されているか、または検索パス中のディレクトリが適切な順序であるか

• ファイルまたはディレクトリに適切なアクセス権や所有権があるか

• ネットワーク経由でアクセスするシステムの構成が変更されているか

この章では、これらの 3 点を確認する方法を簡単に説明して、可能な解決策を提案します。

検索パスに関連する問題を解決する (コマンドが見つかりません)

「コマンドが見つかりません」というメッセージは、次のいずれかを示しています。

• コマンドがそのシステムに存在しない

• コマンドのディレクトリが検索パスに存在しない

検索パスの問題を解決するには、コマンドが格納されているディレクトリのパス名を知る必要があります。

間違ったバージョンのコマンドが見つかってしまうのは、同じ名前のコマンドを持つディレクトリが検索パスにある場合です。この場合、正しいディレクトリが検索パスの後ろの方にあるか、まったく存在しない可能性があります。

現在の検索パスを表示するには、echo $PATH コマンドを使用します。

$ echo $PATH 
/home/kryten/bin:/sbin:/usr/sbin:/usr/openwin/bin:/usr/openwin/bin/xview:
/usr/dist/local/exe:/usr/dist/exe

間違ったバージョンのコマンドを実行しているかどうかを調べるには、which コマンドを使用します。

$ which maker 
/usr/doctools/frame5.1/bin/maker

which コマンドは、.cshrc ファイルの中のパス情報を調べます。.cshrc ファイルに which コマンドの認識する別名を定義している場合に、Bourne シェルか Korn シェルから which コマンドを実行すると、間違った結果が返される場合があります。正しい結果を得るために、which コマンドは C シェルで使用してください。Korn シェルの場合は、whence コマンドを使用します。

検索パスの問題を診断し、解決する方法

1. 現在の検索パスを表示して、コマンドが入っているディレクトリがユーザーのパス内に存在しない (あるいはスペルが間違っている) ことを確認します。

   $ echo $PATH

2. 次の項目を確認します。

   • 検索パスは正しいか

   • 検索パスは、コマンドの他のバージョンが存在する他の検索パスの前に指定されているか

   • 検索パスのいずれかにコマンドが存在するか

   パスを修正する必要がある場合は、手順 3 に進みます。修正する必要がない場合は、手順 4 に進みます。

3. 次の表に示すように、適切なファイルでパスを追加します。

   シェル	ファイル	構文	注
   Bourne と Korn	$HOME/.profile	$ PATH=$HOME/bin:/sbin:/usr/local/bin ... $ export PATH	パス名はコロンで区切る
   C	$HOME/.cshrc または   $HOME/.login	hostname% set path=(‾bin /sbin /usr/local/bin ...)	パス名は空白文字で区切る

4. 次のように、新しいパスを有効にします。

   シェル	パスが指定されているファイル	パスを有効にするコマンド
   Bourne と Korn	.profile	$ . ./.profile
   C	.cshrc	hostname% source .cshrc
   	.login	hostname% source .login

5. 次のコマンドを使用して、パスを確認します。

   $ which command
   

例 - 検索パスの問題を診断および修正する

この例は、which コマンドを使用して、OpenWindows の実行可能ファイルが検索パス中のどのディレクトリにも存在しないことを示しています。

venus% openwin
openwin: コマンドが見つかりません
venus% echo $PATH
no openwin in . /home/ignatz /sbin /usr/sbin /usr/bin /etc /home/ignatz/bin
/bin /home/bin /usr/etc
venus% vi ‾.cshrc(適切なコマンドディレクトリを検索パスに追加する)
venus% source .cshrc
venus% openwin

コマンドを見つけることができなかった場合は、マニュアルページでそのディレクトリパスを調べます。たとえば、lpsched コマンド (lp プリンタデーモン) を見つけることができなかった場合、lpsched(1M) のマニュアルページを調べると、そのパスが /usr/lib/lp/lpsched であることが解かります。

ファイルアクセスの問題を解決する

以前はアクセスできていたファイルまたはディレクトリにアクセスできない場合は、そのファイルまたはディレクトリのアクセス権または所有権が変更されていることがあります。

ファイルとグループの所有権の変更

誰かがスーパーユーザーとしてファイルを編集したために、ファイルやディレクトリの所有権が変更されていることがあります。新しいユーザーのためにホームディレクトリを作成するときは、そのホームディレクトリのドット (.) ファイルの所有者をそのユーザーにしてください。ユーザーが「.」を所有していない場合、そのユーザーは自分のホームディレクトリにファイルを作成できません。

アクセスに関する問題は、グループの所有権が変更されたとき、またはユーザーがメンバーであるグループが /etc/group データベースから削除されたときにも発生します。

表 33-1 に、アクセスに問題があるファイルのアクセス権や所有権の変更方法を示します。

ネットワークアクセスで発生する問題の把握

リモートコピーコマンド rcp を使用してネットワーク上でファイルをコピーするときに問題が発生した場合、リモートシステム上のディレクトリやファイルは、アクセス権の設定によりアクセスが制限されている可能性があります。他に考えられる問題の原因は、リモートシステムとローカルシステムがアクセスを許可するように構成されていないことです。

ネットワークアクセスで発生する問題と AutoFS 経由でシステムにアクセスするときの問題については、『NFS の管理』を参照してください。

第 34 章 印刷時の問題の解決

この章では、印刷サービスの設定または管理の際に発生する可能性のある印刷上の問題を解決する方法について説明します。

この章では次の手順を説明します。

• 「プリンタに出力されない問題を解決する方法」

• 「出力が正しくない場合の問題を解決する方法」

• 「LP 印刷サービスのハングを解除する方法」

• 「アイドル状態になった (ハングした) プリンタの問題を解決する方法」

• 「矛盾したプリンタ状態メッセージを解決する方法」

印刷と LP 印刷サービスの概要については、第 1 章「印刷管理の概要」を参照してください。

問題解決のヒント

プリンタを設定後に、何も印刷されないことがあります。また、若干は処理されるものの、何か印刷しても正しく出力されない、読みづらいなど、期待どおりの結果が得られないことがあります。このような問題が発生すると、他にも次のような問題が発生することがあります。

• LP コマンドがハングする

• プリンタがアイドル状態になる

• ユーザーが矛盾したメッセージを受け取る

この章の推奨事項の多くはパラレルプリンタに関連しますが、より一般的なシリアルプリンタにも当てはまります。

プリンタ追加時の問題の解決方法

Solaris リリースをインストール後 Admintool を使用してリモートプリンタへのアクセスを追加しようとすると、次のメッセージが表示される場合があります。

Admintool: Error
add remote printer failed

この場合は、SunSoft 印刷クライアントソフトウェアがネットワークにインストールされていて、リモートプリンタがすでに利用できる可能性があります。プリンタを追加する前に lpstat -t コマンドを使用して、プリンタが利用できるかどうかを確認してください。

出力されない (印刷されない) 場合の解決方法

何も印刷されないときは、次の部分をチェックします。

• プリンタハードウェア

• ネットワーク

• LP 印刷サービス

バナーページは印刷されるのに他には何も印刷されない場合は、不正な出力の特殊ケースです。「出力が正しくない場合の解決方法」を参照してください。

ハードウェアのチェック

ハードウェアは、最初にチェックすべきポイントです。プリンタが電源に接続され、電源がオンになっているかどうかを確認してください。また、ハードウェア付属のマニュアルを参照して、ハードウェアの設定値を調べてください。コンピュータによっては、プリンタポートの特性を変更するハードウェアスイッチが付いているものがあります。

プリンタハードウェアには、プリンタ、コンピュータへの接続ケーブル、ケーブルの先端を接続するポートが含まれます。一般的なアプローチとしては、プリンタからコンピュータへと順番に調べてください。まず、プリンタをチェックします。次に、ケーブルがプリンタに接続される箇所をチェックします。次に、ケーブルをチェックします。最後に、ケーブルがコンピュータに接続されている箇所をチェックします。

ネットワークのチェック

よく問題が発生するのは、印刷クライアントから印刷サーバーに送られるリモート印刷要求です。印刷サーバーと印刷クライアント間でネットワークアクセスが使用可能になっているかどうかを確認してください。

ネットワークがネットワーク情報サービスプラス (NIS+) を実行している場合は、システム間のアクセスを使用可能にする方法について、『Solaris ネーミングの管理』を参照してください。ネットワークがネットワーク情報サービス (NIS) または NIS+ を実行していない場合は、印刷サーバーと印刷クライアントを設定する前に、印刷サーバー上の /etc/hosts ファイルに各クライアントシステムのインターネットアドレスとシステム名を組み込んでください。また、印刷サーバーのインターネットアドレスとシステム名を、各印刷クライアントシステムの /etc/hosts ファイルに組み込まなければなりません。

LP 印刷サービスのチェック

正常に印刷するには、印刷サーバーと印刷クライアント上で LP スケジューラが動作していなければなりません。動作していない場合は、/usr/lib/lp/lpsched コマンドを使用して起動する必要があります。スケジューラの起動に問題がある場合は、「印刷スケジューラを再起動する方法」を参照してください。

スケジューラが動作している他に、出力する前にプリンタが使用可能になっていて、印刷要求を受け付けられる状態になっていなければなりません。LP 印刷サービスがプリンタへの要求を受け付けなければ、依頼した印刷要求は拒否されます。その場合、一般にユーザーは印刷要求を依頼すると警告メッセージを受け取ります。LP 印刷サービスがプリンタで使用可能になっていないと、印刷要求はプリンタが使用可能になるまでシステム上の待ち行列に残ります。

通常は、次の手順で印刷時の問題を分析してください。

• 手順ごとに印刷要求の経路を追跡します。

• 手順ごとに LP 印刷サービスの状態を調べます。

  • 構成は正しいか

  • プリンタは要求を受け付けるか

  • プリンタは要求を処理できるか

• 要求が転送時にハングしている場合は、syslog.conf 内の lpr.debug を設定して、転送状況を表示します。

• 要求がローカルでハングしている場合は、lpsched ログ (/var/lp/logs/lpsched) を調べます。

• 要求がローカルでハングしている場合は、プリンタデバイスエラー (障害) の通知を送らせ、プリンタを再度使用可能にします。

「印刷時の問題の解決」に掲載されている手順では、この方法を使用して LP 印刷サービスに関する各種の問題に対処する方法を説明します。

LP 印刷サービスの基本的な問題解決の手順で問題を解決できない場合は、当てはまる特定のクライアント/サーバーのケースごとに問題解決の手順を実行する必要があります。

• SunOS 5.7 または互換バージョンの印刷サーバーを使用する、SunOS 5.7 または互換バージョンの印刷クライアント (操作については、「SunOS 5.7 または互換バージョンのクライアントから SunOS 5.7 または互換バージョンの印刷サーバーへの印刷をチェックするには」を参照)

• SunOS 4.1 印刷サーバーを使用する SunOS 5.7 または互換バージョンの印刷クライアント (操作については、「SunOS 5.7 または互換バージョンのクライアントから SunOS 4.1 印刷サーバーへの印刷をチェックするには」を参照)

• SunOS 5.7 または互換バージョンの印刷サーバーを使用する SunOS 4.1 印刷クライアント (操作については、「SunOS 4.1 クライアントから SunOS 5.7 または互換バージョンの印刷サーバーへの印刷をチェックするには」を参照)

出力が正しくない場合の解決方法

プリンタと印刷サービスソフトウェアが正しく構成されていない場合は、プリンタで印刷されても、期待どおりに出力されないことがあります。

プリンタタイプとファイル内容形式のチェック

LP 印刷サービスでプリンタを設定するときに間違ったプリンタタイプを使用すると、不適切なプリンタ制御文字がプリンタに送られる可能性があります。その結果は予測できません。何も印刷されない、出力が読みづらい、正しい文字セットやフォントで印刷されないなどの結果となります。

SunOS 5.7 または互換バージョンの印刷クライアント、あるいは SunOS 5.7 または互換バージョンの印刷サーバーで間違ったファイル内容形式を指定した場合、バナーページは印刷できますが、他には何も印刷されません。プリンタに指定されたファイル内容形式は、プリンタがフィルタなしで直接印刷できるファイル形式を示します。ユーザーがプリンタにファイルを送信すると、ファイルはフィルタなしでプリンタに直接送信されます。プリンタがその形式を処理できないときは、問題が発生します。

印刷クライアントの設定時には、ファイル内容形式が印刷サーバーと印刷クライアントの両方で正しくなければならないので、間違いをおかす機会が多くなります。推奨する方法は、印刷クライアントのファイル内容形式を any に設定することです。こうすると、ファイルはサーバーに直接送信され、フィルタが必要かどうかはサーバー側で決定されます。したがってファイル内容形式は、サーバー側だけで正しく指定すればよいことになります。

印刷クライアント側でファイル内容を指定し、フィルタリングの負荷をサーバーからクライアントに移すことができますが、内容の形式は印刷サーバー側でサポートしなければなりません。

stty 設定値のチェック

デフォルトの stty (標準端末) 設定値がプリンタから要求される設定値と一致しないと、多数のフォーマット上の問題が生じる可能性があります。この後の節では、設定値の一部が間違っているときに発生する問題について説明します。

ボーレート設定値が正しくない場合

コンピュータのボーレート設定値がプリンタのボーレート設定値と一致しないときは、通常何か出力されますが、希望する出力は得られません。特殊文字や不要なスペースが異常に混じったランダムな出力が表示されます。LP 印刷サービスのデフォルトは 9600 ボーレートです。

プリンタがパラレルポートで接続されている場合、ボーレート設定値は関係ありません。

パリティ設定値が正しくない場合

プリンタによっては、パリティビットを使用して、印刷用に受け取ったデータに伝送中に誤りがなかったことを確認するものがあります。コンピュータとプリンタのパリティビットの設定値は一致しなければなりません。一致しない場合、文字によってはまったく印刷されないか、他の文字で置き換えられることもあります。その出力は文字間隔が正しく、ほとんどの文字が正しい位置にあるので、一見正しいように見えます。LP 印刷サービスの場合、デフォルトではパリティビットは設定されません。

タブ設定値が正しくない場合

ファイルにタブが含まれていても、プリンタがタブを予期していなければ、印刷出力にはファイルの内容が完全に印刷されますが、テキストは右マージンに対して正確に配置されないことがあります。また、プリンタのタブ設定が間違っていると、テキストに左マージンがない、テキストがつながってしまう、テキストがページの一部分に集中する、間違ってダブルスペースになってしまうなどの問題が発生します。デフォルトでは、タブは 8 スペースごとに設定されます。

Return 設定値が正しくない場合

出力がシングルスペースのはずなのにダブルスペースになる場合は、プリンタのタブ設定値が間違っているか、プリンタが Return の後に 1 行追加されています。LP 印刷サービスは、改行の前に 1 つ Return を追加するので、その組み合わせによって 2 行の改行が発生します。

ジグザグに印刷される場合は、改行の前に Return を送る stty オプションの onlcr が設定されていません。stty=onlcr オプションはデフォルトで設定されますが、他の印刷問題を解決しようとしたときに、それを消去した可能性があります。

ハングした LP 印刷サービスコマンドの解決方法

lp コマンド (lpsystem、lpadmin、lpstat など) を入力しても何も発生しない (エラーメッセージ、状態情報、またはプロンプトが表示されない) 場合は、LP スケジューラに問題が発生した可能性があります。このような問題は、通常は LP スケジューラを停止して再起動すれば解決できます。操作手順については、「印刷スケジューラを停止する方法」と 「印刷スケジューラを再起動する方法」を参照してください。

アイドル状態になった (ハングした) プリンタの解決方法

プリンタが印刷要求を待ち行列に入れているのに、アイドル状態になっていることがあります。プリンタがアイドル状態になっている場合は、次の原因が考えられます。

• 現在の印刷要求にフィルタがかけられている

• プリンタに障害がある

• ネットワーク上の問題が原因で、印刷処理が中断されている

印刷フィルタのチェック

低速印刷フィルタは、プリンタを拘束しないようにバックグラウンドで実行されます。フィルタリングが必要な印刷要求は、フィルタリングが終わるまで印刷されません。

プリンタ障害のチェック

LP 印刷サービスが障害を検出すると、印刷はすぐにではありませんが自動的に再開されます。LP 印刷サービスは約 5 分間待機し、要求が正常に印刷されるまで試行し続けます。プリンタを使用可能にすると、すぐに再試行できます。

ネットワーク上の問題のチェック

ネットワーク経由でファイルを印刷するときには、次の問題が発生することがあります。

• 印刷サーバーに送られた要求が、クライアントシステム (ローカル) の待ち行列で停止する

• 印刷サーバーに送られた要求が、印刷サーバー (リモート) の待ち行列で停止する

ローカル待ち行列で停止する印刷要求

印刷サーバーに依頼された印刷要求は、次の原因でクライアントシステムの待ち行列で停止することがあります。

• 印刷サーバーがダウンしている

• プリンタが印刷サーバー側で使用不可にされている

• 印刷クライアントと印刷サーバー間のネットワークがダウンしている

• ベースになる SunOS 5.7 または互換バージョンのネットワークソフトウェアが適切に設定されていない

問題の原因を突き止めるときには、新しい要求を待ち行列に追加しないでください。詳細は、「プリンタへの印刷要求を受け付けるまたは拒否する方法」 を参照してください。

リモート待ち行列で停止する印刷要求

印刷要求が印刷サーバーの待ち行列で停止する場合は、プリンタが使用不可になっている可能性があります。プリンタが要求を受け付けても処理しないとき、その要求は印刷するために待ち行列に入れられます。プリンタを使用可能にすると、それ以外に問題がなければ、待ち行列内の印刷要求は印刷されます。

矛盾した状態メッセージの解決方法

ユーザーが印刷要求を入力すると、クライアントシステムからは受け付けられたことが通知され、印刷サーバーからは印刷要求が拒否されたことを示すメールを受け取ることがあります。これらの矛盾したメッセージは、次の原因で発生することがあります。

• 印刷クライアントは要求を受け付けることができても、印刷サーバーは要求を拒否している場合

• 印刷クライアント側のプリンタの定義が、印刷サーバー側のプリンタの定義と一致しない場合。特に、フィルタ、文字セット、印字ホイール、フォームなど、印刷ジョブコンポーネントの定義が、クライアントとサーバーシステムの間で一致していない場合

ローカルユーザーが印刷サーバー上でプリンタにアクセスできるように、これらのジョブコンポーネントの定義が印刷クライアントと印刷サーバーの両方で登録されているかどうかを確認してください。

印刷時の問題の解決

この節では、次の手順について説明します。

• 出力されない問題を解決する方法

• 出力が正しくない問題を解決する方法

• LP コマンドのハングを解除する方法

• アイドル状態になった (ハングした) プリンタの問題を解決する方法

• 矛盾した状態メッセージを解決する方法

プリンタに出力されない問題を解決する方法

この作業には、次の問題解決の手順が含まれています。印刷要求をプリンタに出したのに何も印刷されない場合は、これらの手順を試してください。

• ハードウェアをチェックする (「ハードウェアをチェックするには」を参照)

• ネットワークをチェックする (「ネットワークをチェックするには」を参照)

• LP 印刷サービスの基本機能をチェックする (「LP 印刷サービスの基本機能をチェックするには」を参照)

• SunOS 5.7 または互換バージョンの印刷クライアントから SunOS 5.7 または互換バージョンの印刷サーバーへの印刷をチェックする (「SunOS 5.7 または互換バージョンのクライアントから SunOS 5.7 または互換バージョンの印刷サーバーへの印刷をチェックするには」を参照)

• SunOS 5.7 または互換バージョンの印刷クライアントから SunOS 4.1 印刷サーバーへの印刷をチェックする (「SunOS 5.7 または互換バージョンのクライアントから SunOS 4.1 印刷サーバーへの印刷をチェックするには」を参照)

• SunOS 4.1 印刷クライアントからSunOS 5.7 または互換バージョンの印刷サーバーへの印刷をチェックする (「SunOS 4.1 クライアントから SunOS 5.7 または互換バージョンの印刷サーバーへの印刷をチェックするには」を参照)

該当する印刷クライアント/サーバーのケースに進む前に、上記のうち最初の 3 つの手順をリストの順に試してください。ただし、バナーページは印刷されるが他に何も印刷されない場合は、「出力が正しくない場合の問題を解決する方法」の説明に進んでください。

ハードウェアをチェックするには

1. プリンタがコンセントに接続され、電源がオンになっているか確認します。

2. ケーブルがプリンタのポートと、システムまたはサーバーのポートに接続されているか確認します。

3. そのケーブルが正しいケーブルであり、欠陥がないことを確認します。

   詳細は、ハードウェア付属のマニュアルを参照してください。プリンタがシリアルポートに接続されている場合は、そのケーブルでハードウェアフロー制御がサポートされることを確認してください。NULL モデムアダプタでは、この機能がサポートされます。表 34-1 は、NULL モデムケーブル用のピン構成を示しています。

   表 34-1 NULL モデムケーブル用のピン構成

   	ホスト	プリンタ
   Mini-Din-8	25-Pin D-sub	25-Pin D-sub
   -	1(FG)	1(FG)
   3(TD)	2(TD)	3(RD)
   5(RD)	3(RD)	2(TD)
   6(RTS)	4(RTS)	5(CTS)
   2(CTS)	5(CTS)	4(RTS)
   4(SG)	7(SG)	7(SG)
   7(DCD)	6(DSR)、8(DCD)	20(DTR)
   1(DTR)	20(DTR)	6(DSR)、8(DCD)

4. ポート用のハードウェアスイッチが正しく設定されていることを確認します。

   正しい設定については、プリンタのマニュアルを参照してください。

5. プリンタが動作するか確認します。

   プリンタにセルフテスト機能が付いている場合は、その機能を使用します。プリンタのセルフテストの詳細は、プリンタのマニュアルを参照してください。

6. コンピュータとプリンタのボーレートの設定値が正しいか確認します。

   コンピュータとプリンタのボーレートの設定値が一致しなければ、何も印刷されないことがあり、さらに正しく出力されない場合もあります。詳細は、「出力が正しくない場合の問題を解決する方法」を参照してください。

ネットワークをチェックするには

1. ping コマンドを使用すると、印刷サーバーと印刷クライアント間のネットワークが正しく設定されているか確認できます。

   print_client# ping print_server 
   print_server is alive
   print_server# ping print_client 
   print_client not available

   システムが動作していることを示すメッセージが表示されれば、そのシステムにアクセスできることがわかるので、そのネットワークは正常です。また、このメッセージは、入力したホスト (システム) 名が、ネームサーバーまたはローカルの /etc/hosts ファイルによって IP アドレスに変換されたことを示します。変換されていない場合は、IP アドレスを入力する必要があります。

   「not available」というメッセージが表示された場合は、次の 3 点を確認してください。まず、NIS または NIS+ はサイトでどのように設定されているか。次に、印刷サーバーと印刷クライアントが相互に通信できるように付加的な作業が必要か。最後に、サイトが NIS または NIS+ を実行していない場合、各印刷クライアントの /etc/hosts ファイルに印刷サーバーの IP アドレスを入力し、印刷サーバーの /etc/hosts ファイルにすべての印刷クライアントの IP アドレスを入力したか確認します。

2. (SunOS 5.0 - 5.1 印刷サーバーのみ) listen ポートモニターが正しく構成されているか確認します。

3. (SunOS 5.0 - 5.1 印刷サーバーのみ) ネットワーク待機サービスが印刷サーバー上のポートモニターに登録されているか確認します。

LP 印刷サービスの基本機能をチェックするには

この手順では、基本 LP 印刷サービス機能をチェックする例として、プリンタ luna を使用しています。

1. 印刷サーバー上と印刷クライアント上で、LP 印刷サービスが動作していることを確認します。

   1. このコマンドは、LP スケジューラが動作しているか表示します。

      # lpstat -r
      scheduler is running

   2. スケジューラが動作していない場合は、スーパーユーザーまたは lp になり、スケジューラを起動します。

      # /usr/lib/lp/lpsched
      

      スケジューラを起動できない場合は、「LP 印刷サービスのハングを解除する方法」を参照してください。

2. 印刷サーバー上と印刷クライアント上で、プリンタが要求を受け付けていることを確認します。

   1. プリンタが要求を受け付けていることを確認します。

      # lpstat -a
      mars accepting requests since Jun 16 10:37 1998
      luna not accepting requests since Jun 16 10:37 1998
      unknown reason

      このコマンドは、LP システムがシステム用に構成された各プリンタの要求を受け付けているか確認します。

   2. プリンタが要求を受け付けていない場合は、スーパーユーザーまたは lp になり、プリンタが印刷要求を受け付けるようにします。

      # accept luna
      

      これで、指定したプリンタは要求を受け付けます。

3. 印刷サーバー上と印刷クライアント上で、プリンタが依頼された印刷要求の印刷で使用可能になっているか確認します。

   1. プリンタが使用可能になっていることを確認します。

      # lpstat -p luna
      printer luna disabled since Jun 16 10:40 1998.
      available.
      unknown reason

      このコマンドは、プリンタの状態に関する情報を表示します。プリンタ名を省略すると、システム用に設定されたすべてのプリンタに関する情報を表示できます。次の例は、使用不可になっているプリンタを示しています。

   2. プリンタが使用不可になっている場合は、スーパーユーザーまたは lp になり、プリンタを使用可能にします。

      # enable luna
      printer "luna" now enabled.

      指定したプリンタが、印刷要求の処理に使用可能になります。

4. 印刷サーバー上で、プリンタが正しいシリアルポートに接続されていることを確認します。

   1. プリンタが正しいシリアルポートに接続されていることを確認します。

      # lpstat -t
      scheduler is running
      system default destination: luna
      device for luna: /dev/term/a

      「device for printer-name」というメッセージは、ポートアドレスを示します。LP 印刷サービスの接続先のポートにケーブルが接続されているか確認します。ポートが正しければ、手順 5 に進みます。

   2. スーパーユーザーまたは lp になります。

   3. ポートを表すデバイスファイルのファイル所有権を変更します。

      # chown lp device-filename
      

      このコマンドは、特殊なユーザー lp をデバイスファイルの所有者として割り当てます。このコマンドで、device-filename はデバイスファイル名です。

   4. プリンタポートのデバイスファイルのアクセス権を変更します。

      # chmod 600 device-filename
      

      このコマンドにより、root または lp だけがプリンタポートデバイスファイルにアクセスできます。

5. 印刷サーバー上と印刷クライアント上で、プリンタが正しく構成されていることを確認します。

   1. プリンタが適切に設定されていることを確認します。

      # lpstat -p luna -l
      printer luna is idle. enabled since Jun 16 10:38 1998. available.
              Content types: postscript
              Printer types: PS

      上の例は、正しく設定された PostScript プリンタと、そのプリンタを印刷要求の処理に利用できることを示しています。プリンタタイプとファイル内容形式が正しい場合は、手順 6 に進みます。

   2. プリンタタイプまたはファイル内容形式が違っている場合は、印刷クライアント上で、プリンタタイプを unknown に設定し、内容形式を any に設定してください。

      # lpadmin -p printer-name -T printer-type -I file-content-type
      

6. 印刷サーバー上で、プリンタがプリンタ障害のために待機していないことを確認します。

   1. プリンタ障害のためにプリンタが待機していないことを確認します。

      # lpadmin -p printer-name -F continue 
      

      このコマンドは LP 印刷サービスに対して、障害のために待機していない場合は続行するように指示します。

   2. プリンタを再び使用可能にすることによって、すぐに再試行させます。

      # enable printer-name 
      

   3. (省略可能) プリンタ障害をすぐに通知するように、LP 印刷サービスに指示します。

      # lpadmin -p printer-name -A 'write root'
      

      このコマンドは LP 印刷サービスに対して、プリンタが障害を起こした場合に、root に書き込むというデフォルトポリシーを設定し、root がログインした端末にプリンタ障害メッセージを送るように指示します。これにより、問題を修正するときに障害通知をすぐに受け取れます。

7. プリンタがログイン端末として間違った設定になっていないか確認します。

   ---

   注 -

   ログイン端末としてプリンタを設定する作業では誤りをおかしやすいので、当てはまらないと思われる場合にも、必ず設定値を確認してください。

   ---

   1. ps -ef コマンドの出力で、プリンタポートのエントリを探します。

      # ps -ef
          root   169   167  0   Apr 04 ?        0:08 /usr/lib/saf/listen tcp
          root   939     1  0 19:30:47 ?        0:02 /usr/lib/lpsched
          root   859   858  0 19:18:54 term/a   0:01 /bin/sh -c ¥ /etc/lp/
      interfaces/luna
      luna-294 rocket!smith "passwd¥n##
      #

      このコマンドの出力で、プリンタポートのエントリを探します。上の例で、ポート /dev/term/a はログイン端末として間違って設定されています。この行の最後に "passwd¥n## 情報が付いているのでわかります。ポートが正しく設定されている場合は、この手順の最後を飛ばしてください。

   2. 印刷要求を取り消します。

      # cancel request-id
      

      このコマンドで、request-id は取り消したい印刷要求の要求 ID 番号です。

   3. プリンタポートをログインデバイス以外のものとして設定します。

      # lpadmin -p printer-name -h
      

   4. ps -ef コマンドからの出力をチェックして、プリンタポートがログインデバイスではなくなったことを確認します。

      基本的な LP 印刷サービス機能に印刷時の問題の原因が見つからない場合は、次の中から該当するクライアント/サーバーの手順に進んでください。

SunOS 5.7 または互換バージョンのクライアントから SunOS 5.7 または互換バージョンの印刷サーバーへの印刷をチェックするには

1. まだチェックしていなければ、印刷サーバー上で LP 印刷サービスの基本機能をチェックします。

   基本機能をチェックする手順については、「LP 印刷サービスの基本機能をチェックするには」を参照してください。印刷クライアントから要求が出されたときに何も印刷されない原因を探す前に、プリンタがローカルで正しく動作することを確認してください。

2. まだチェックしていなければ、印刷クライアント上で LP 印刷サービスの基本機能をチェックします。

   基本機能をチェックする手順については、「LP 印刷サービスの基本機能をチェックするには」を参照してください。クライアントからの要求が印刷される前に、印刷クライアント上で LP スケジューラが動作していなければならず、またプリンタが使用可能であり、要求を受け付けられる状態になっていなければなりません。

   ---

   注 -

   次の手順のほとんどは、root または lp としてログインして実行しなければなりません。

   ---

3. 印刷サーバーがアクセス可能であることを確認します。

   1. 印刷クライアント上で、ping print-server と入力して Return キーを押します。このコマンドにより、印刷サーバーに応答を求める要求が送られます。

      print_client# ping print_server
      

      「print_server not available」というメッセージを受け取った場合は、ネットワークに問題があります。

4. SunOS 5.1 印刷クライアント上でのみ、Admintool の「プリンタの変更 (Modify Printer)」ウィンドウを表示して、印刷サーバーのタイプが s5 になっていることを確認します。

5. 印刷サーバーが正常に動作しているか確認します。

   # lpstat -t luna
   scheduler is running
   system default destination: luna
   device for luna: /dev/term/a
   luna accepting requests since Jun 16 10:39 1998. available.
   printer luna now printing luna-314. enabled since Jun 16 10:39 1998. 
   available.
   luna-129            root               488   Jun 16 10:45
   #

   上記の例は、印刷サーバーが動作していることを示します。

6. 印刷サーバーが正常に動作していない場合は、手順 1 に戻ります。

SunOS 5.7 または互換バージョンのクライアントから SunOS 4.1 印刷サーバーへの印刷をチェックするには

1. まだチェックしていなければ、印刷クライアント上で LP 印刷サービスの基本機能をチェックします。

   手順については、「LP 印刷サービスの基本機能をチェックするには」を参照してください。

2. 印刷サーバーがアクセス可能であることを確認します。

   1. 印刷クライアント上で、ping print-server と入力して Return キーを押します。このコマンドにより、印刷サーバーに応答を求める要求が送られます。

      print_client# ping print_server
      

      「print_server not available」というメッセージを受け取った場合は、ネットワークに問題があります。

3. 印刷サーバー上で lpd デーモンが動作していることを確認します。

   1. 次のコマンドを実行して、印刷サーバー上で lpd デーモンが動作していることを確認します。

      $ ps -ax | grep lpd
        126 ?  IW    0:00 /usr/lib/lpd
        200 p1 S     0:00 grep lpd
      $

      lpd デーモンが動作している場合は、上記の例のような 1 行が表示されます。動作していなければ、プロセス情報は表示されません。

   2. lpd が印刷サーバー上で動作していない場合は、印刷サーバー上でスーパーユーザーになり、lpd を再起動します。

      # /usr/lib/lpd &
      

4. 印刷サーバーの lpd デーモンが正しく構成されていることを確認します。

   1. 印刷サーバー上でスーパーユーザーになり、lpc コマンドを入力します。

      # /usr/etc/lpc
      lpc>

   2. LP 状態情報を取得します。

      lpc> status
      luna:
      queuing is enabled
      printing is enabled
      no entries
      no daemon present
      lpc>

      状態情報が表示されます。上記の例では、デーモンは動作していないので再起動する必要があります。

   3. デーモンが存在しない場合は、デーモンを再起動します。

      lpc> restart luna
      

      デーモンが再起動されます。

   4. lpd デーモンが起動されていることを確認します。

      lpc> status
      

   5. lpc コマンドを終了します。

      lpc> quit
      

      シェルプロンプトが再表示されます。

5. 印刷クライアントが印刷サーバーにアクセスできることを確認します。

   1. 4.1 印刷サーバー上に /etc/hosts.lpd ファイルがあるか確認します。

      4.1 印刷サーバー上では、このファイルが存在する場合、着信印刷要求を受け付けられるかどうかの判定に使用されます。このファイルが存在しない場合、すべての印刷クライアントシステムがアクセスできるため、次の手順の b と c は省略します。

   2. ファイルが存在する場合、印刷クライアントがファイルにリストされるか調べます。

      ファイルにリストされていないクライアントシステムからの要求は、印刷サーバーに転送されません。

   3. クライアントがリストされていない場合は、印刷クライアントをファイルに追加します。

      ---

      注 -

      ここまでで特に問題点が見つからない場合、SunOS 4.1 システムは正常に設定され、機能しているはずです。

      ---

6. 印刷クライアントからリモート lpd 印刷デーモンへの接続が正しく行われていることを確認します。

   1. 印刷クライアント上でスーパーユーザーになり、lpsched デーモンが実行されていることを確認します。

      # ps -ef | grep lp
         root   154     1 80   Jan 07 ?        0:02 /usr/lib/lpsched

      上記の例のように、lpsched デーモンは動作しているはずです。

   2. LP 印刷サービスを停止します。

      # lpshut
      

   3. LP 印刷サービスを再起動します。

      # /usr/lib/lp/lpsched
      

7. リモート印刷サーバーが SunOS 4.1 システムとして正しく識別されていることを確認します。

SunOS 4.1 クライアントから SunOS 5.7 または互換バージョンの印刷サーバーへの印刷をチェックするには

1. まだチェックしていなければ、印刷サーバー上で LP 印刷サービスの基本機能をチェックします。

   手順については、「LP 印刷サービスの基本機能をチェックするには」を参照してください。印刷クライアントから要求が出されたときに何も印刷されない原因を調べる前に、プリンタがローカルで動作していることを確認してください。

   ---

   注 -

   次の手順で指定されているシステムでは、スーパーユーザーまたは lp としてログインする必要があります。

   ---

2. 印刷クライアントにアクセスできることを確認します。

   1. SunOS 5.7 印刷サーバー上で、ping print-client と入力して Return キーを押します。

      print_server# ping print_clientprint_client is alive

      「print_client not available」というメッセージが表示された場合は、ネットワークに問題があります。

3. 印刷クライアント上で、プリンタが正しく設定されていることを確認します。

   # lpr -P luna /etc/fstab
   lpr: cannot access luna
   #

   このコマンドでは、印刷クライアントが動作しているか表示されます。上記の例は、印刷クライアントが正常に動作していないことを示します。

4. 印刷クライアント上で lpd デーモンが動作していることを確認します。

   1. lpd デーモンが動作していることを確認します。

      # ps -ax | grep lpd
        118 ?  IW    0:02 /usr/lib/lpd
      #

      このコマンドでは、lpd デーモンが印刷クライアント上で動作しているか表示されます。上記の例は、デーモンが動作していることを示します。

   2. 印刷クライアント上で、lpd デーモンを起動します。

      # /usr/lib/lpd &
      

5. 印刷クライアント上で、印刷サーバーを識別する printcap エントリが存在することを確認します。

   1. プリンタが認識されていることを確認します。

      # lpr -P mercury /etc/fstab
      lpr: mercury: unknown printer
      #

      上記の例は、指定したプリンタのエントリが /etc/printcap ファイルに入っていないことを示します。

   2. エントリがない場合は、/etc/printcap ファイルを編集して次の情報を追加します。

      printer-name|print-server:¥
      :lp=:rm=print-server:rp=printer-name:br#9600:rw:¥ 
      :lf=/var/spool/lpd/printer-name/log:¥
      :sd=/var/spool/lpd/printer-name:

      次の例は、印刷サーバー neptune に接続されたプリンタ luna のエントリを示します。

      luna|neptune:¥
              :lp=:rm=neptune:rp=luna:br#9600:rw:¥
              :lf=/var/spool/lpd/luna/log:¥
              :sd=/var/spool/lpd/luna:

   3. プリンタのスプーリングディレクトリ (/var/spool/lpd/printer-name) を作成します。

6. 再試行を強制し、印刷クライアント lpd が待機状態になっていないことを確認します。

   印刷サーバーが動作し応答している場合、印刷クライアント lpd は再試行する前に待ち状態になっている可能性があります。

   1. 印刷クライアント上でスーパーユーザーとなり、lpc コマンドを起動します。

      lpc> プロンプトが表示されます。

   2. プリンタを再起動します。

   3. lpc コマンドを終了します。

      シェルプロンプトが再表示されます。

      # lpc
      lpc> restart luna
      luna:
             no daemon to abort
      luna:
            daemon started
      # quit
      $

7. 印刷サーバーへの接続を調べます。

   1. 印刷クライアント上でスーパーユーザーになり、プリンタのログファイルを調べます。

      # more /var/spool/lpd/luna/log
      

      通常、何も表示されません。

   2. プリンタ状態ログも調べます。

      # more /var/spool/lpd/luna/status
      waiting for luna to come up
      #

   3. 接続が正常な場合は、印刷サーバー上で印刷サーバーが正しく設定されているかを確認します。

      # lpstat -t
      scheduler is running
      system default destination: luna
      device for luna: /dev/term/a
      luna accepting requests since Jun 16 10:41 1998
      printer luna now printing luna-314. enabled since 
      Jun 16 10:41 1998. available.
      luna-314            root               488   Jun16 10:41
      #

      上記の例は、印刷サーバーが起動され、動作していることを示します。

      印刷サーバーが動作していない場合は、先に進む前に 手順 1 に戻ってください。

出力が正しくない場合の問題を解決する方法

1. スーパーユーザーまたは lp としてログインします。

2. プリンタタイプが正しいことを確認します。

   プリンタタイプが正しくないと、正しく出力されないことがあります。たとえば、プリンタタイプ PS を指定してページを逆順に印刷する場合は、プリンタタイプ PSR を試してください (この 2 つのタイプ名は大文字で指定しなければなりません)。また、プリンタタイプが正しくないと、テキストの欠落、読みづらいテキスト、または間違ったフォントのテキストが出力されることがあります。プリンタタイプを判別するには、terminfo データベース内のエントリを調べます。terminfo データベースの構造については、「プリンタタイプ」を参照してください。

   1. 印刷サーバー上で、プリンタの特性を表示します。

      $ lpstat -p luna -l
      printer luna is idle. enabled since Jun 16 10:43 1998. 
      available.
      	Form mounted: 
      	Content types: any
      	Printer types: NeWSprinter20
      	Description: 
      	Connection: direct
      	Interface: /etc/lp/interfaces/alamosa
      	After fault: continue
      	Users allowed:
      		(all)
      	Forms allowed:
      		(none)
      	Banner not required
      	Character sets:
      		
      	Default pitch:
      	Default page size: 80 wide 66 long
      	Default port settings:  
      $

   2. プリンタのマニュアルを参照して、プリンタのモデルを調べます。

   3. プリンタタイプが正しくない場合は、Admintool の「プリンタの変更 (Modify Printer)」オプションを使用して変更するか、次の lpadmin コマンドを使用します。

      # lpstat -p printer-name -T printer-type
      

      印刷クライアント上では、プリンタタイプを unknown にしてください。印刷サーバー上では、プリンタタイプは使用するプリンタのモデルをサポートするように定義された terminfo エントリと一致しなければなりません。使用するプリンタのタイプに関する terminfo エントリがない場合は、「サポートされていないプリンタの terminfo エントリを追加する方法」を参照してください。

3. バナーページは印刷されるが文書の本文が印刷されない場合は、ファイル内容形式を確認します。

   プリンタに指定したファイル内容形式は、プリンタがフィルタなしで直接印刷できるファイル形式を示します。ファイル内容形式が正しくなければ、必要なときにフィルタリングがバイパスされることがあります。

   1. 前の手順の lpstat コマンドで表示されたファイル内容形式に関する情報をメモします。

      印刷クライアント上では、1 つ以上の明示的な内容形式を指定する理由がない限り、ファイル内容形式を any にしてください。クライアント上で内容を指定すると、印刷サーバー上ではなく印刷クライアント上でフィルタリングが実行されます。また、クライアント上の内容形式は、印刷サーバー上で指定した内容形式と一致しなければならず、印刷サーバー上の内容形式はプリンタの機能を反映していなければなりません。

   2. プリンタのマニュアルを参照し、プリンタで直接印刷できるファイルのタイプを判別します。

      これらのファイル形式を参照するために使用する名前は、プリンタメーカーが使用している名前と一致しなくてもかまいません。ただし、使用する名前は LP 印刷サービスに認識されるフィルタで使用する名前と一致しなければなりません。

   3. ファイル内容形式が正しくない場合は、Admintool の「プリンタの変更 (Modify Printer)」オプションで変更するか、次の lpadmin コマンドを使用します。

      # lpadmin -p printer-name -I file-content-type(s)
      

      必要に応じて、このコマンドを印刷クライアント上、印刷サーバー上、またはその両方で実行します。印刷クライアント上で -I any を試し、印刷サーバー上で -I "" を試してください。-I "" は、NULL のファイル内容形式リストを指定します。これは、プリンタはそのプリンタタイプと正確に一致するファイルしか直接印刷できないので、すべてのファイルをフィルタにかけることを意味します。

      ファイルが印刷されないときは、まずこの組み合わせを選択してみるとよいでしょう。それで成功したら、印刷サーバー上で明示的な内容形式を指定し、不要なフィルタリングを減らすことができます。ローカルの PostScript プリンタでは、プリンタでサポートされている場合は、postscript または postscript,simple を使用してください。PS と PSR はファイル内容形式ではなく、プリンタタイプなので注意してください。

      -I を省略すると、ファイル内容のリストはデフォルトの simple になります。-I オプションを使用し、simple 以外にもファイル内容形式を指定したい場合は、リストに simple を含めなければなりません。

      複数のファイル内容形式を指定するときは、名前をコンマで区切ります。また、名前をスペースで区切り、リストを引用符で囲むこともできます。ファイル内容形式として any を指定すると、フィルタリングは行われないので、プリンタで直接印刷できるファイルタイプのみを送信する必要があります。

4. フォントのダウンロードに必要なフィルタリングを、印刷要求がバイパスしていないかどうかをチェックします。

   ユーザーがコマンド lp -T PS を使用して印刷要求を PostScript プリンタに依頼すると、フィルタリングは実行されません。フィルタリングを強制するコマンド lp -T postscript を使用して要求を依頼しようとすると、文書に必要な非常駐フォントがダウンロードされることがあります。

5. プリンタポートの stty 設定値が正しいことを確認します。

   1. プリンタのマニュアルを参照して、プリンタポートに合った stty 設定値を判別します。

      ---

      注 -

      プリンタがパラレルポートで接続されている場合、ボーレートの設定値は無関係です。

      ---

   2. 現在の設定値を調べるには、stty コマンドを使用します。

      # stty -a < /dev/term/a
      speed 9600 baud;
      rows = 0; columns = 0; ypixels = 0; xpixels = 0;
      eucw 1:0:0:0, scrw 1:0:0:0
      intr = ^c; quit = ^|; erase = ^?; kill = ^u;
      eof = ^d; eol = <undef>; eol2 = <undef>; swtch = <undef>;
      start = ^q; stop = ^s; susp = ^z; dsusp = ^y;
      rprnt = ^r; flush = ^o; werase = ^w; lnext = ^v;
      parenb -parodd cs7 -cstopb -hupcl cread -clocal -loblk -parext
      -ignbrk brkint -ignpar -parmrk -inpck istrip -inlcr -igncr icrnl -iuclc
      ixon -ixany -ixoff imaxbel
      isig icanon -xcase echo echoe echok -echonl -noflsh
      -tostop echoctl -echoprt echoke -defecho -flusho -pendin iexten
      opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel tab3
      #

      このコマンドでは、プリンタポートの現在の stty 設定値が表示されます。

      LP 印刷サービスの標準プリンタインタフェースプログラムで使用されるデフォルトの stty オプションを表 34-2 に示します。

      表 34-2 標準インタフェースプログラムで使用されるデフォルトの stty 設定値

      オプション	意味
      -9600	ボーレートを 9600 に設定
      -cs8	8 ビットバイトを設定
      -cstopb	1 バイト当たり 1 ストップビットを送信
      -parity	パリティを生成しない
      -ixon	XON/XOFF (START/STOP または DC1/DC3 ともいう) を使用可能にする
      -opost	以下にリストされた設定値をすべて使用して「処理後出力」を実行する
      -olcuc	小文字を大文字に割り当てない
      -onlcr	改行をキャリッジリターン/改行に変更する
      -ocrnl	キャリッジリターンを改行に変更しない
      -onocr	カラム 0 でもキャリッジリターンを出力する
      -n10	改行後の遅延なし
      -cr0	キャリッジターン後の遅延なし
      -tab0	タブ後の遅延なし
      -bs0	バックスペース後の遅延なし
      -vt0	垂直タブ後の遅延なし
      -ff0	用紙送り後の遅延なし

   3. stty 設定値を変更します。

      # lpadmin -p printer-name -o "stty= options" 
      

      表 34-3 を使用して、印刷出力に影響する様々な問題を解決する stty オプションを選択します。

      表 34-3 印刷出力の問題を解決する stty オプション

      stty 値	結果	間違った設定から起こり得る問題
      110, 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, 38400	ボーレートを指定した値に設定する (ボーレートを 1 つだけ入力する)	ランダム文字と特殊文字が印刷され、間隔がバラバラになることがある
      oddp evenp -parity	奇数パリティを設定する  偶数パリティを設定する  パリティを設定しない	文字が欠落または間違った文字がランダムに表示される
      -tabs	タブを設定しない	テキストが右マージンにくっついてしまう
      tabs	8 スペースごとにタブを設定する	テキストに左マージンがなく、つながってしまうか、くっついてしまう
      -onlcr	行頭でキャリッジリターンを設定しない	間違ったダブルスペース
      onlcr	行頭でキャリッジリターンを設定する	ジグザグに印刷される

      オプションをスペースで区切り、オプションリストを単一引用符で囲むと、複数のオプションの設定を変更できます。たとえば、奇数パリティを使用可能にし、7 ビットの文字サイズを設定する必要のあるプリンタを仮定します。そのためには、次の例のようなコマンドを入力します。

      # lpadmin -p neptune -o "stty='parenb parodd cs7'"
      

      stty オプション parenb でパリティチェック/生成を使用可能にし、parodd で奇数パリティの生成を設定し、cs7 で文字サイズを 7 ビットに生成します。

6. 文書が正しく印刷されることを確認します。

   # lp -d printer-name filename
   

LP 印刷サービスのハングを解除する方法

1. スーパーユーザーまたは lp としてログインします。

2. LP 印刷サービスを停止します。

   # lpshut
   

   このコマンドがハングする場合は、Control-c キーを押して次の手順に進みます。このコマンドが正常に実行された場合は、手順 4 に進みます。

3. LP のプロセス ID を確認します。

   # ps -el | grep lp
      134 term/a   0:01 lpsched
   #

   次の手順の pid には、最初のカラムのプロセス ID 番号 (PID) を使用します。

4. kill -15 コマンドを使用して、LP プロセスを停止します。

   # kill -15 134
   

   これで LP 印刷サービスプロセスが停止します。プロセスが停止しない場合は、最後の手段として手順 5 に進みます。

5. 最後の手段として、プロセスを強制終了します。

   # kill -9 134
   

   すべての lp プロセスが終了します。

6. 次のコマンドでは、LP 印刷サービスを再起動できるように、SCHEDLOCK ファイルが削除されます。

   # rm /usr/spool/lp/SCHEDLOCK
   

7. LP 印刷サービスを再起動します。

   # /usr/lib/lp/lpsched
   

   LP 印刷サービスが再起動されます。スケジューラが再起動されない場合は、「印刷スケジューラを再起動する方法」を参照してください。

アイドル状態になった (ハングした) プリンタの問題を解決する方法

この作業には、プリンタがアイドル状態であってはならないのにアイドル状態になるときに使用する多数の手順が含まれています。通常は各手順を順番に試しますが、順番どおりでなくてもかまいません。

プリンタの準備ができているかチェックするには

1. プリンタ状態情報を表示します。

   # lpstat -p printer-name 
   

   表示される情報は、プリンタがアイドル状態かアクティブ状態か、使用可能か使用不可か、または印刷要求を利用できるか受け付けていないかを示します。すべて正常と思われる場合は、この節の他の手順に進んでください。lpstat コマンドを実行できない場合は、「LP 印刷サービスのハングを解除する方法」を参照してください。

2. プリンタが利用できない (要求を受け付けていない) 場合は、プリンタが要求を受け付けるようにします

   # accept printer-name 
   

   プリンタは、その印刷待ち行列に要求を受け付け始めます。

3. プリンタが使用不可になっている場合は、再び使用可能にします。

   # enable printer-name 
   

   このコマンドでは、待ち行列にある要求を処理するように、プリンタを再び使用可能にします。

印刷のフィルタリングをチェックするには

lpstat -o コマンドを使用して、印刷のフィルタリングをチェックします。

$ lpstat -o luna
luna-10           fred         1261   Mar 12 17:34 being filtered
luna-11           iggy         1261   Mar 12 17:36 on terra
luna-12           jack         1261   Mar 12 17:39 on terra
$

待機している最初の要求がフィルタリングされているかどうかを調べます。上の例のような出力になる場合は、ファイルがフィルタリングされています。プリンタはハングせず、要求の処理に少し時間がかかっているだけです。

プリンタ障害の後に印刷を再開するには

1. プリンタ障害に関するメッセージがある場合は、その障害を解決してください。

   プリンタ障害の警告がどのように指定されているかに応じて、メッセージを電子メールで root に送らせるか、root がログインした端末に書き出すことができます。

2. プリンタを再び使用可能にします。

   # enable printer-name 
   

   プリンタ障害によって要求がブロックされた場合は、このコマンドで強制的に再試行します。このコマンドが動作しない場合は、この節の他の手順を続行します。

ローカル待ち行列で停止している印刷要求をリモートプリンタに送信するには

1. 印刷クライアント上で、印刷サーバーへの印刷要求を、それ以上待ち行列に入れないようにします。

   # reject printer-name 
   

2. 印刷クライアント上で、印刷サーバーに ping 要求 (存在をチェックする要求) を送信します。

   print_client# ping print_server
   print_server is alive

   「print_server not available」というメッセージが表示される場合は、ネットワークに問題があります。

3. 問題を解決したら、新しい印刷要求を待ち行列に入れられるようにします。

   # accept printer-name 
   

4. 必要であれば、再びプリンタを使用可能にします。

   # enable printer-name 
   

印刷サーバーの待ち行列で停止する印刷クライアントからの印刷要求を使用可能にするには

1. 印刷サーバー上で、印刷クライアントから印刷サーバーへの印刷要求を、それ以上待ち行列に入れないようにします。

   # reject printer-name 
   

2. lpsched ログファイルを表示します。

   # more /var/lp/logs/lpsched
   

   表示される情報を参考にして、印刷クライアントから印刷サーバーへの印刷要求が印刷されない原因を正確に把握できます。

3. 問題を解決したら、新しい印刷要求を待ち行列に入れられるようにします。

   # accept printer-name
   

4. 必要であれば、印刷サーバー上で再びプリンタを使用可能にします。

   # enable printer-name
   

矛盾したプリンタ状態メッセージを解決する方法

1. 印刷サーバー上でプリンタが使用可能になっており、要求を受け付けているかどうかを確認します。

   # lpstat -p printer-name
   

   印刷クライアントが要求を受け付けているのに、印刷サーバーが要求を拒否しているときは、矛盾した状態メッセージが表示されます。

2. 印刷サーバー上で、印刷クライアント上のプリンタの定義が、印刷サーバー上のプリンタの定義と一致するかどうかを確認します。

   # lpstat -p -l printer-name
   

   印刷フィルタ、文字セット、印字ホイール、フォームなど、印刷ジョブコンポーネントの定義を調べて、印刷クライアントとサーバー上で一致し、ローカルユーザーが印刷サーバーシステムのプリンタにアクセスできることを確認します。

第 35 章 ファイルシステムで発生する問題の解決

この章で説明する情報は次のとおりです。

• 「fsck の一般エラーメッセージ」

• 「初期化フェーズでの fsck メッセージ」

• 「フェーズ 1: ブロックとサイズに関するメッセージのチェック」

• 「フェーズ 1B : 走査し直して DUPS メッセージを表示する」

• 「フェーズ 2: パス名メッセージのチェック」

• 「フェーズ 3: 接続性メッセージのチェック」

• 「フェーズ 4: 参照数メッセージのチェック」

• 「フェーズ 5: シリンダグループメッセージのチェック」

• 「クリーンアップフェーズのメッセージ」

fsck プログラムと、fsck プログラムを使用してファイルシステムの整合性をチェックする方法については、『Solaris のシステム管理 (第 1 巻)』の「ファイルシステムの整合性チェック」を参照してください。

エラーメッセージ

通常、システムが異常終了し、ファイルシステムの最新の変更がディスクに書き込まれなかった場合に、fsck が非対話形式で実行され、ファイルシステムが修復されます。修復されると、ファイルシステムの基本的な非整合状態は自動的に修正されますが、より重大なエラーは修復されません。ファイルシステムを修復する間に、fsck はこの種の異常終了から予想される非整合状態を修正します。より重大な状況の場合は、エラーが表示されて終了します。

fsck を対話形式で実行すると、fsck は見つかった各非整合状態を表示して小さなエラーを修正します。ただし、より重大なエラーの場合は、非整合状態を表示し、応答を選択するように促します。-y または -n オプションを指定して fsck を実行する場合、fsck が提案するデフォルト応答には、ユーザー側の応答がエラー条件ごとに yes または no にあらかじめ定義されています。

修正処置によっては、若干のデータが失われます。失われるデータの量は、fsck の診断出力から判断できます。

fsck はマルチパスファイルシステムのチェックプログラムです。パスごとに、異なるメッセージセットを使用して fsck プログラムの異なるフェーズが呼び出されます。初期化後に、fsck はファイルシステムごとに連続パスを実行して、ブロックとサイズ、パス名、接続状態、参照数、空きブロックマップをチェックします (再構築することもあります)。また、何らかのクリーンアップも実行します。

UFS バージョンの fsck によって実行されるフェーズ (パス) は次のとおりです。

• 初期化

• フェーズ 1 - ブロックとサイズのチェック

• フェーズ 2 - パス名のチェック

• フェーズ 3 - 接続状態のチェック

• フェーズ 4 - 参照数のチェック

• フェーズ 5 - シリンダグループのチェック

この後の各節では、各フェーズで検出できるエラー条件、表示されるメッセージとプロンプト、および応答できる内容について説明します。

複数のフェーズで表示されるメッセージについては、「fsck の一般エラーメッセージ」を参照してください。それ以外の場合、メッセージは発生するフェーズのアルファベット順に掲載されています。

多くのメッセージには、表 35-1 に示す省略形が含まれています。

また、多くのメッセージには、i ノード番号などの変数フィールドが含まれています。このマニュアルでは、i ノード番号を inode-number のようにイタリック体で掲載してあります。たとえば、次の画面メッセージは、

INCORRECT BLOCK COUNT I=2529

次の例のように掲載されています。

INCORRECT BLOCK COUNT I=inode-number

fsck の一般エラーメッセージ

この節のエラーメッセージは、初期化後のどのフェーズでも表示されることがあります。処理を続けるかどうかのオプションは表示されますが、通常は、致命的だと見なすのが最善の処置です。これらのエラーメッセージは重大なシステム障害を反映しており、ただちに処理する必要があります。この種のメッセージが表示された場合は、n(o) を入力してプログラムを終了してください。問題の原因を判断できない場合は、ご購入先に問い合わせてください。

CANNOT SEEK: BLK block-number (CONTINUE)

CANNOT READ: BLK block-number (CONTINUE)

CANNOT WRITE: BLK block-number (CONTINUE)

初期化フェーズでの fsck メッセージ

初期化フェーズでは、コマンド行構文がチェックされます。ファイルシステムのチェックを実行する前に、fsck はテーブルを設定してファイルを開きます。

この節のメッセージは、コマンド行オプション、メモリー要求、ファイルのオープン、ファイルの状態、ファイルシステムのサイズチェック、およびスクラッチファイルの作成によるエラー条件に関するものです。ファイルシステムを修復する間に、どんな初期化エラーが発生した場合も、fsck は終了します。

bad inode number inode-number to ginode

cannot alloc size-of-block map bytes for blockmap
 
cannot alloc size-of-free map bytes for freemap
 
cannot alloc size-of-state map bytes for statemap
 
cannot alloc size-of-lncntp bytes for lncntp

Can't open checklist file: filename

Can't open filename

Can't stat root

Can't stat filename
Can't make sense out of name filename

filename: (NO WRITE)

IMPOSSIBLE MINFREE=percent IN SUPERBLOCK (SET TO DEFAULT)

filename: BAD SUPER BLOCK: message
USE AN ALTERNATE SUPER-BLOCK TO SUPPLY NEEDED INFORMATION;
e.g., fsck[-f ufs] -o b=# [special ...]
where # is the alternate superblock.  See fsck_ufs(1M)

CPG OUT OF RANGE
FRAGS PER BLOCK OR FRAGSIZE WRONG
INODES PER GROUP OUT OF RANGE
INOPB NONSENSICAL RELATIVE TO BSIZE 
MAGIC NUMBER WRONG 
NCG OUT OF RANGE 
NCYL IS INCONSISTENT WITH NCG*CPG 
NUMBER OF DATA BLOCKS OUT OF RANGE
NUMBER OF DIRECTORIES OUT OF RANGE
ROTATIONAL POSITION TABLE SIZE OUT OF RANGE
SIZE OF CYLINDER GROUP SUMMARY AREA WRONG
SIZE TOO LARGE 
BAD VALUES IN SUPERBLOCK

UNDEFINED OPTIMIZATION IN SUPERBLOCK (SET TO DEFAULT)

フェーズ 1: ブロックとサイズに関するメッセージのチェック

このフェーズでは、i ノードリストをチェックします。次の処理中に検出されたエラー条件が表示されます。

• i ノードのタイプをチェックする

• ゼロリンク数テーブルを設定する

• 不良ブロックまたは重複ブロックの有無を i ノードブロック番号で検査する

• i ノードのサイズをチェックする

• i ノードの形式をチェックする

ファイルシステムの修復 (preen) 中は、INCORRECT BLOCK COUNT、 PARTIALLY TRUNCATED INODE、 PARTIALLY ALLOCATED INODE、および UNKNOWN FILE TYPE を除き、このフェーズのどのエラーが発生した場合も、fsck が終了します。

このフェーズでは、その他に次のエラーメッセージが表示される可能性があります。

• BAD STATE state-number TO BLKERR

• block-number DUP I=inode-number

• EXCESSIVE BAD BLOCKS I=inode-number (CONTINUE)

• EXCESSIVE DUP BLKS I=inode-number (CONTINUE)

• INCORRECT BLOCK COUNT I=inode-number (number-of-BAD-DUP-or-missing-blocks should be number-of-blocks-in-filesystem) (CORRECT)

• LINK COUNT TABLE OVERFLOW (CONTINUE)

• PARTIALLY ALLOCATED INODE I=inode-number (CLEAR)

• PARTIALLY TRUNCATED INODE I=inode-number (SALVAGE)

• UNKNOWN FILE TYPE I=inode-number (CLEAR)

フェーズ 1 では、次のメッセージ (アルファベット順) が発生する可能性があります。

block-number BAD I=inode-number

BAD MODE: MAKE IT A FILE?

BAD STATE state-number TO BLKERR

block-number DUP I=inode-number

DUP TABLE OVERFLOW (CONTINUE)

EXCESSIVE BAD BLOCKS I=inode-number (CONTINUE)

EXCESSIVE DUP BLKS I=inode-number (CONTINUE)

INCORRECT BLOCK COUNT I=inode-number 
 (number-of-BAD-DUP-or-missing-blocks should be 
number-of-blocks-in-filesystem) (CORRECT)

LINK COUNT TABLE OVERFLOW (CONTINUE)

PARTIALLY ALLOCATED INODE I=inode-number (CLEAR)

PARTIALLY TRUNCATED INODE I=inode-number (SALVAGE)

UNKNOWN FILE TYPE I=inode-number (CLEAR)

フェーズ 1B : 走査し直して DUPS メッセージを表示する

ファイルシステム内で重複ブロックが見つかると、次のメッセージが表示されます。

block-number DUP I=inode-number

フェーズ 2: パス名メッセージのチェック

このフェーズでは、フェーズ 1 と 1B で見つかった不良 i ノードを指すディレクトリエントリが削除される。次の原因でエラー条件が表示される。

• 不正なルート i ノードモードと状態

• 範囲外のディレクトリ i ノードポインタ

• 不良 i ノードを指すディレクトリエントリ

• ディレクトリ完全性チェック

ファイルシステムを修復している場合は (-o p (preen、修復) オプション)、このフェーズでどのエラーが発生した場合も、fsck が終了します。ただし、ブロックサイズの倍数でないディレクトリ、重複ブロックと不良ブロック、範囲外の i ノード、過剰なハードリンクに関連するエラーは除きます。

このフェーズでは、他に次のエラーメッセージが表示されることがあります。

• BAD INODE state-number TO DESCEND

• BAD INODE NUMBER FOR '.' I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time DIR=filename (FIX)

• BAD INODE NUMBER FOR '..' I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time DIR=filename (FIX)

• BAD RETURN STATE state-number FROM DESCEND

• BAD STATE state-number FOR ROOT INODE

• BAD STATE state-number FOR INODE=inode-number

• DIRECTORY TOO SHORT I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time DIR=filename (FIX)

• DIRECTORY filename: LENGTH file-size NOT MULTIPLE OF block-number (ADJUST)

• DIRECTORY CORRUPTED I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time DIR=filename (SALVAGE)

• DUP/BAD I=inode-number OWNER=O MODE=M SIZE=file-size MTIME=modification-time TYPE=filename (REMOVE)

• DUPS/BAD IN ROOT INODE (REALLOCATE)

• EXTRA '.' ENTRY I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time DIR=filename (FIX)

• EXTRA '..' ENTRY I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time DIR=filename (FIX)

• hard-link-number IS AN EXTRANEOUS HARD LINK TO A DIRECTORY filename (REMOVE)

• inode-number OUT OF RANGE I=inode-number NAME=filename (REMOVE)

• MISSING '.' I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time DIR=filename (FIX)

• MISSING '.' I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time DIR=filename CANNOT FIX, FIRST ENTRY IN DIRECTORY CONTAINS filename

• MISSING '.' I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time DIR=filename CANNOT FIX, INSUFFICIENT SPACE TO ADD '.'

• MISSING '..' I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time DIR=filename (FIX)

• MISSING '..' I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time DIR=filename CANNOT FIX, SECOND ENTRY IN DIRECTORY CONTAINS filename

• MISSING '..' I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time DIR=filename CANNOT FIX, INSUFFICIENT SPACE TO ADD '..'

• NAME TOO LONG filename

• ROOT INODE UNALLOCATED (ALLOCATE)

• ROOT INODE NOT DIRECTORY (REALLOCATE)

• UNALLOCATED I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time type=filename (REMOVE)

• ZERO LENGTH DIRECTORY I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time DIR=filename (REMOVE)

BAD INODE state-number TO DESCEND

BAD INODE NUMBER FOR '.' I=inode-number OWNER=UID MODE=file-mode SIZE=file-size
MTIME=modification-time DIR=filename (FIX)

BAD INODE NUMBER FOR '..' I=inode-number OWNER=UID MODE=file-mode SIZE=file-size
MTIME=modification-time DIR=filename (FIX)

BAD RETURN STATE state-number FROM DESCEND

BAD STATE state-number FOR ROOT INODE

BAD STATE state-number FOR INODE=inode-number

DIRECTORY TOO SHORT I=inode-number OWNER=UID MODE=file-mode SIZE=file-size 
MTIME=modification-time DIR=filename (FIX)

DIRECTORY filename: LENGTH file-size NOT MULTIPLE OF block-number (ADJUST)

DIRECTORY CORRUPTED I=inode-number OWNER=UID MODE=file-mode SIZE=file-size 
MTIME=modification-time DIR=filename (SALVAGE)

DUP/BAD I=inode-number OWNER=O MODE=M SIZE=file-size 
MTIME=modification-time TYPE=filename (REMOVE)

DUPS/BAD IN ROOT INODE (REALLOCATE)

EXTRA '.' ENTRY I=inode-number OWNER=UID MODE=file-mode SIZE=file-size
MTIME=modification-time DIR=filename (FIX)

EXTRA '..' ENTRY I=inode-number OWNER=UID MODE=file-mode SIZE=file-size 
MTIME=modification-time DIR=filename(FIX)

hard-link-number IS AN EXTRANEOUS HARD LINK TO A DIRECTORY filename (REMOVE)

inode-number OUT OF RANGE I=inode-number NAME=filename (REMOVE)

MISSING '.' I=inode-number OWNER=UID MODE=file-mode SIZE=file-size 
MTIME=modification-time DIR=filename (FIX)

MISSING '.' I=inode-number OWNER=UID MODE=file-mode SIZE=file-size 
MTIME=modification-time DIR=filename CANNOT FIX, FIRST ENTRY IN 
DIRECTORY CONTAINS filename

MISSING '.' I=inode-number OWNER=UID MODE=file-mode SIZE=file-size 
MTIME=modification-time DIR=filename CANNOT FIX, INSUFFICIENT SPACE TO ADD '.'

MISSING '..' I=inode-number OWNER=UID MODE=file-mode SIZE=file-size 
MTIME=modification-time DIR=filename (FIX)

MISSING '..' I=inode-number OWNER=UID MODE=file-mode SIZE=file-size 
MTIME=modification-time DIR=filename CANNOT FIX, SECOND ENTRY IN DIRECTORY 
CONTAINS filename

MISSING '..' I=inode-number OWNER=UID MODE=file-mode SIZE=file-size 
MTIME=modification-time DIR=filename CANNOT FIX, INSUFFICIENT SPACE TO ADD '..'

NAME TOO LONG filename

ROOT INODE UNALLOCATED (ALLOCATE)

ROOT INODE NOT DIRECTORY (REALLOCATE)

UNALLOCATED I=inode-number OWNER=UID MODE=file-mode SIZE=file-size 
MTIME=modification-time type=filename(REMOVE)

ZERO LENGTH DIRECTORY I=inode-number OWNER=UID MODE=file-mode SIZE=file-size 
MTIME=modification-time DIR=filename (REMOVE)

フェーズ 3: 接続性メッセージのチェック

このフェーズでは、フェーズ 2 で検査したディレクトリがチェックされ、次の原因によるエラー条件が表示されます。

• 参照されないディレクトリ

• 欠落しているか、フルになっている lost+found ディレクトリ

このフェーズでは、他に次のようなエラーメッセージが表示されます。

• BAD INODE state-number TO DESCEND

• DIR I=inode-number1 CONNECTED. PARENT WAS I=inode-number2

• DIRECTORY filename LENGTH file-size NOT MULTIPLE OF block-number (ADJUST)

• lost+found IS NOT A DIRECTORY (REALLOCATE)

• NO lost+found DIRECTORY (CREATE)

• NO SPACE LEFT IN /lost+found (EXPAND)

• UNREF DIR I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time (RECONNECT)

BAD INODE state-number TO DESCEND

DIR I=inode-number1 CONNECTED. PARENT WAS I=inode-number2

DIRECTORY filename LENGTH file-size NOT MULTIPLE OF block-number (ADJUST)

lost+found IS NOT A DIRECTORY (REALLOCATE)

NO lost+found DIRECTORY (CREATE)

NO SPACE LEFT IN /lost+found (EXPAND)

UNREF DIR I=inode-number OWNER=UID MODE=file-mode SIZE=file-size 
MTIME=modification-time (RECONNECT)

フェーズ 4: 参照数メッセージのチェック

このフェーズでは、フェーズ 2 と 3 で取得したリンク数情報がチェックされます。次の原因によるエラー条件が表示されます。

• 非参照ファイル

• 見つからないか、lost+found ディレクトリがフル

• ファイル、ディレクトリ、シンボリックリンク、または特殊ファイルの不正なリンク数

• 非参照ファイル、シンボリックリンク、ディレクトリ

• ファイルとディレクトリ内の不良ブロックまたは重複ブロック

• 不正な合計空き i ノード数

このフェーズのすべてのエラー (lost+found ディレクトリ内の容量不足を除く) は、ファイルシステムを修復するときに解決できます。

このフェーズでは、他に次のエラーメッセージが表示されることがあります。

• BAD/DUP type I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time (CLEAR)

• (CLEAR)

• LINK COUNT type I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time COUNT link-count SHOULD BE corrected-link-count (ADJUST)

• lost+found IS NOT A DIRECTORY (REALLOCATE)

• NO lost+found DIRECTORY (CREATE)

• NO SPACE LEFT IN /lost+found (EXPAND)

• UNREF FILE I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time (RECONNECT)

• UNREF type I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time (CLEAR)

• ZERO LENGTH DIRECTORY I=inode-number OWNER=UID MODE=file-mode SIZE=file-size MTIME=modification-time (CLEAR)

BAD/DUP type I=inode-number OWNER=UID MODE=file-mode SIZE=file-size 
MTIME=modification-time (CLEAR)

(CLEAR)

LINK COUNT type I=inode-number OWNER=UID MODE=file-mode SIZE=file-size
MTIME=modification-time COUNT link-count SHOULD BE corrected-link-count (ADJUST)

lost+found IS NOT A DIRECTORY (REALLOCATE)

NO lost+found DIRECTORY (CREATE)

NO SPACE LEFT IN / lost+found (EXPAND)

UNREF FILE I=inode-number OWNER=UID MODE=file-mode SIZE=file-size 
MTIME=modification-time (RECONNECT)

UNREF type I=inode-number OWNER=UID MODE=file-mode SIZE=file-size 
MTIME=modification-time (CLEAR)

ZERO LENGTH DIRECTORY I=inode-number OWNER=UID MODE=file-mode SIZE=file-size 
MTIME=modification-time(CLEAR)

フェーズ 5: シリンダグループメッセージのチェック

このフェーズでは、空きブロックと使用済み i ノードのマップがチェックされます。次の原因によるエラー条件が表示されます。

• 使用済み i ノードマップから欠落している割り当て済み i ノード

• 空きブロックマップから欠落している空きブロック

• 使用済み i ノードマップ内の空き i ノード

• 不正な合計空きブロック数

• 不正な合計使用済み i ノード数

このフェーズでは、他に次のエラーメッセージが表示されることがあります。

• BLK(S) MISSING IN BIT MAPS (SALVAGE)

• CG character-for-command-option: BAD MAGIC NUMBER

• SUMMARY INFORMATION BAD (SALVAGE)

• number-of files, number-of-files used, number-of-files free (number-of frags, number-of blocks, percent fragmentation)

• ***** FILE SYSTEM WAS MODIFIED *****

• filename FILE SYSTEM STATE SET TO OKAY

• filename FILE SYSTEM STATE NOT SET TO OKAY

BLK(S) MISSING IN BIT MAPS (SALVAGE)

CG character-for-command-option: BAD MAGIC NUMBER

FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGE)

SUMMARY INFORMATION BAD (SALVAGE)

クリーンアップフェーズのメッセージ

ファイルシステムのチェックが終わると、クリーンアップ処理がいくつか実行されます。クリーンアップフェーズでは、次の状態メッセージが表示されます。

number-of files, number-of-files used, number-of-files free (number-of frags, 
number-of blocks, percent fragmentation)

上記のメッセージは、チェックされたファイルシステムに、フラグメントサイズの number-of 個のブロックを使用中の number-of 個のファイルが入っていることと、ファイルシステム内でフラグメントサイズのブロックが number-of 個空いていることを示します。括弧内の数は、空いている数を number-of 個の空きフラグメント、number-of 個の完全サイズの空きブロック、および percent のフラグメントに分割したものです。

***** FILE SYSTEM WAS MODIFIED *****

上記のメッセージは、ファイルシステムが fsck によって変更されたことを示します。このファイルシステムがマウントされているか、現在のルート (/) ファイルシステムの場合はリブートします。ファイルシステムがマウントされている場合は、マウント解除して再び fsck を実行する必要があります。そうしないと、fsck によって実行された処理がテーブルのインコアコピー (カーネル内のコピー) によって取り消されます。

filename FILE SYSTEM STATE SET TO OKAY

上記のメッセージは、ファイルシステム filename に安定を示すマークが付けられたことを示します。-m オプションを指定して fsck を実行すると、この情報を使用して、ファイルシステムのチェックが必要かどうかが判断されます。

filename FILE SYSTEM STATE NOT SET TO OKAY

上記のメッセージは、ファイルシステム filename に安定を示すマークが付いていないことを示します。-m オプションを指定して fsck を実行すると、この情報を使用して、ファイルシステムにチェックが必要かどうかが判断されます。

第 36 章 ソフトウェア管理の問題の解決

この章では、ソフトウェアパッケージをインストールまたは削除するときに発生する問題について説明します。この章には、2 つの節があります。「特定のソフトウェア管理エラー」では、パッケージのインストールエラーと管理エラーについて説明します。「一般的なソフトウェア管理障害」では、特定のエラーメッセージを出さない障害について説明します。

この章の内容は次のとおりです。

• 「特定のソフトウェア管理エラー」

• 「一般的なソフトウェア管理時の問題」

ソフトウェアパッケージの管理については、『Solaris のシステム管理 (第 1 巻)』の「ソフトウェア管理の概要」を参照してください。

特定のソフトウェア管理エラー

WARNING: filename <not present on Read Only file system>

一般的なソフトウェア管理時の問題