クライアントのデータベース (インデックス) ファイルが 2G バイトよりも大きいため、保存が失敗し、このエラーが表示されます。Solaris 2.6 リリースおよび SBU 5.0.1 では、この問題は発生しません。
旧バージョンの Solaris ソフトウェアでは、nwadmin を開く「Indexes」-> 適切なクライアンの選択 -> 適切な fs の選択 ->「Remove oldest cycle」->「Reclaim space」の順で処理を行う必要があります。
十分なスペースを確保するには、この操作を何度か繰り返す必要があります。インデックスが必要な場合は、scanner コマンドを使用して後で作成できます。
この障害が発生する最大の原因は、動作確認されていないのハードウェアにあります。PC 市場に出回っている SCSI デバイスの中には、UNIX 市場の製品に求められる高速入出力の要件を満たしていないものがあります。また、他の原因として、配線または終端の設定が不適切、電力が不安定といったことも考えられます。このパリティエラーがあるとデータ転送は行われないため、データが損傷している可能性は低くなります。
バス上のすべての SCSI デバイスがサンの動作確認されたハードウェアであることを確認します。次に、すべてのケーブルの合計が 6 メートル未満であり、すべての SCSI 接続部が正しく終端されていることを確認します。電力が不安定な場合は、無停電電源装置を取り付けてください。
このメッセージは、システムが SCSI バスを通じてデータを送信したが、SCSI バスがリセットされたために、データが送信先に到着しなかったことを示します。最も一般的な原因は、SCSI ターゲットの重複です。この障害があるとデータ転送は行われないため、データが損傷している可能性は低くなります。
すべてのケーブルの合計が 6 メートル未満であることと、すべての SCSI 接続が正しく終端されていることを確認します。電力のサージが問題である場合は、サージサプレッサまたは無停電電源装置を入手します。
マシンの内蔵ディスクドライブは、通常、SCSI ターゲット 3 です。外部および二次ディスクドライブがターゲット 1、2、または 0 になっていて、相互に重複していないことを確認します。また、テープドライブがターゲット 4 または 5、CD ドライブが 6 になっていて、相互に、またはディスクドライブと重複していないことも確認してください。内蔵ディスクドライブのターゲット設定に問題がある場合は、一度マシンの電源を切り、すべての外部ドライブを外してから電源を入れて、PROM モニタから probe-scsi-all コマンドまたは probe-scsi コマンドを実行します。
SCSI デバイスのターゲット設定に問題がない場合は、メモリー構成に問題がある可能性があります。大容量のメモリーチップ (4 M バイト SIMM などの) は下側のバンク、小容量のメモリーチップ (1 M バイト SIMM などの) は上側のバンクに装着されていることを確認します。
なお、SPARC システムはすべての Sun 社製以外の CD-ROM ドライブをサポートしているわけではないため、unknown vendor のようなエラーメッセージが表示される場合があります。CD-ROM のベンダに固有の構成要件を問い合わせてください。
Sun 社製以外のディスクドライブの中には、Solaris デバイスドライバを防げる先読みキャッシュを備えたものがあります。既存の先読みキャッシュ機能がある場合は、オフに設定しておいてください。
SCSI ターゲットの詳細は、『Solaris 移行ガイド』のデバイスの命名規則に関する節を参照してください。AnswerBook のオンラインマニュアルを使用している場合は、「SCSI targets」と入力して検索文字列として使用します。
AdminSuite でユーザーを作成する際に、NIS+ サーバーとは異なるシステム上にユーザーのホームディレクトリを配置しようとすると、このエラーメッセージが表示されます。
Security exception on host hostname. USER ACCESS DENIED. The user identity (555) username was received, but that user is not authorized to execute the requested functionality on this system. Is this user a member of an appropriate security group on this system ? (Function: class directory method create_dir) |
ユーザーは NIS+ テーブルでシステム管理グループに登録されていませんでした。
# niscat group.org_dir | grep sysadmin sysadmin::14: |
セグメント例外は、通常、プログラミングエラーによって発生します。読み取り専用ファイルシステムを除き、通常、このメッセージはコアダンプを伴います。
core(4) ファイルを作成したプログラムを特定するには、file(1) コマンドまたは adb(1) コマンドを実行します。dtmail プログラムによって作成された core ファイルに対して file と adb の各コマンドを実行した場合の出力例を次に示します。
$ file core core: ELF 32-bit MSB core file SPARC Version 1, from `dtmail' |
$ adb core core file = core -- program `dtmail' SIGSEGV 11: segmentation violation ^D (adb プログラムを終了するには Control-d と入力します。) |
プロセスが、保護されているかまたは存在しないメモリー領域へアクセスしようとしたことを示すシグナルを受信しました。セグメント例外の最も一般的な 2 つの原因は、ヌルポインタを用いて関接参照をしようとした、または境界を越える添字で配列を参照したことです。
/etc/nsswitch.conf ファイルの中のエントリ sendmailvars: dns nis files が原因で、メッセージがコンソールウィンドウに表示されます。
sendmailvars データベースは、ローカルファイルまたは NIS+、あるいはその両方でだけ使用できます。このデータベースが設定されていない場合、/etc/nsswitch.conf ファイル内のデフォルトの sendmailvars エントリは、次のようになります。
sendmailvars: files |
NIS を実行していて、複数の NIS マシンでこのエラーを受け取りました。
次の内容を確認してください。
稼働しなかったシステムについては、/var/yp/nicknames ファイルがあることを確認します。また、このファイルにエントリ aliases mail.aliases が含まれていることを確認します。
稼働しなかったシステムのどれかで、次のコマンドを実行します。
ypcat aliases |
「no such map in servers domain」というメッセージが表示されるはずです。ypwhich を実行して、システムが結合されている NIS サーバーを確認します。次に、そのサーバーに移動し、mail.aliases マップが /var/yp/domainname にないことを確認します。このマップは作成されるか、このマップがある NIS サーバーのどれかからコピーされる必要があります。
これは、コンソールと /var/adm/messages ログファイルに表示される sendmail(1) メッセージです。このメッセージが特定のユーザーに関して一度だけ表示された場合は、そのユーザーのメールメッセージが行の途中で終わっている (行末の改行文字がない) 可能性があります。このメッセージが頻繁に表示されるか、またはビジー時に表示される場合、他のネットワークエラーが表示されているときは特に、ネットワーク障害を示している可能性があります。
そのユーザーのメールスプールファイルを調べて、メッセージの最後に改行文字があるか確認します。改行文字がある場合は、障害が再現しないようにする方法をユーザーと相談します。これらのメッセージの原因がネットワーク障害にある場合は、メールスプールディレクトリを、高速なネットワークインタフェースを備えた別のマシンに移動する方法もあります。
DATA フェーズの SMTP 受信中に、行の最後がピリオドで終了しているメッセージが到着しなかったため、sendmail(1M) が時間切れになり、このエラーが発生しました。
このメッセージは、OpenWindows のセレクションサービスが、要求されたセレクション項目を /tmp/winselection から取得することに失敗したことを示しています。
次の解析を検討してください。要求されたセレクションは、0 不明、1 キャレット、2 プライマリ、3 セカンダリ、4 クリップボードのどれかです。結果は、0 失敗、2 存在しない、3 所有していない、4 ランクの違い、5 継続、6 キャンセル、7 認識できないのどれかです。
システムに、/etc/mnttab への書き込みに関する障害があります。/etc を含むファイルシステムが読み取り専用にマウントされているか、またはマウントされていない可能性があります。
このファイルが存在するかどうか、およびルートによる書き込みが可能かどうかを確認します。いずれも正しいなら、/etc ファイルシステムがマウントされていること、および読み取り専用ではなく、読み取り/書き込みモードでマウントされていることを確認します。
通常、このメッセージは、システムに、/home にマウントされたローカルファイルシステムがあることを示します。通常、/home は、オートマウンタがユーザーのホームディレクトリをマウントする場所です。
システムがオートマウンタを実行しているときは、ローカルファイルシステムを /home ディレクトリにマウントしないでください。/disk2 など、別のディレクトリにマウントします。ほとんどのシステムでは、新規のディレクトリを作成することになります。オートマウンタの auto_home エントリを変更することもできますが、前者の解決方法の方がより簡単です。
この場合、インストール中 OpenWindows を起動直後に「Signal 8 error」が表示され、インストールが停止します。
システムを「慎重に」シャットダウンし、再起動時に ZIP ドライブカートリッジ (未使用または使用済み) を ZIP ドライブに挿入します。Solaris IA ソフトウェアの標準インストールを開始します。このエラーの後にカートリッジを ZIP ドライブに挿入して Solaris ソフトウェアの既存のインストールを続けることはできません。Solaris ソフトウェアでハードウェアのすべての検査が終了すると、ZIP ドライブは別のハードドライブとして認識され、そこから読み取ろうとします。ドライブにカートリッジがない場合、Signal 8 error が表示されます。Solaris ソフトウェアのインストールで、ZIP ドライブのカートリッジが認識されると、カートリッジにデータがなくても読み取りが行われ、処理が継続します。
これは、ライセンスインターネットメールサーバーの問題です。Solaris 2.6 IA リリースを実行中の Pentium 2 PC に、SIMS 3.1 のデパートメント・エディションをインストールしようとしました。システムは Java インタフェースを使用中であり、上記のエラーが表示されます。ライセンスセンターが発行する 2 つのライセンスファイルは次のとおりです。
SERVER server DAEMON lic.SUNW /etc/opt/licenses/lic.SUNW INCREMENT SLAPD.1 lic.SUNW 1.000 08-Mar-1998 1 SERVER nwlab4 727a2b6a 7588 DAEMON suntechd /etc/opt/licenses/suntechd /etc/opt/licenses/daemon_options INCREMENT sun.mail.mbox suntechd 3.100 08-Mar-1998 100 |
2 つのライセンスファイルをマージし、余分な SERVER 行を削除します。
metatool を使用して状態の複製をディスクのシリンダ 0 に追加しようとすると、次のエラーメッセージが表示されます。
Your attempt to attach metastate database replicas on slice "c?t?d?s?" failed for the following reason: Slice c?t?d?s? is too small to contain 1 replicas. |
これはディスクラベルを保護するために、metatool は最外周のシリンダを使用しないようにしているからです。DiskSuite 4.1 では、metatool は 2.1G バイト以上のディスク上のシリンダ 0 にデータベースを追加できます。
スライスの先頭シリンダを 0 ではなく 1 にするか、コマンド行から metadb -a を実行することによりこの問題を回避できます。
Cisco FDDI カードで Solaris 2.6 リリースを実行中に上記のエラーを受け取りました。
Solaris 2.6 ソフトウェアでは、起動スクリプトは /etc/rc3.d に組み込まれています。これで snmpdx (ポート 161 を使用) を起動します。FDDI SNMP エージェントが実行中であり、すでにポート 161 を宣言しているのでエラーメッセージが表示されます。解決方法は、次の 2 通りあります。
snmpdx が起動しないよう、snmpdx 起動スクリプトを移動します。
mv /etc/rc3.d/S76snmpdx /etc/rc3.d/s76snmpdx |
FDDI が、161 以外のポートを使用できるか調べます。
ソケットタイプのサポートがシステムに設定も実装もされていません。
このエラーの記号名は、ESOCKTNOSUPPORT、errno=121 です。
このメッセージは、Exabyte または DAT テープが (回復可能な) ソフトエラーを大量に生成した場合に、SCSI テープドライブによって表示されます。この後に、「Please, replace tape cartridge」というアドバイスメッセージが表示されます。ソフトエラーは、まもなくハードエラーが発生して、データが損傷する可能性があることを示しています。
まず、メーカーが推奨するクリーニングテープを使用してテープヘッドをきれいにします。この対策が無効な場合、テープカートリッジを交換します。それでも解決できない場合は、テープドライブとテープカートリッジを交換する必要があるかもしれません。
ホストマシン内の原因で、接続のアボートが発生しました。
このエラーの記号名は、ECONNABORTED、errno=130 です。
RFS に特有のエラーです。このエラーは、リソースがまだリモートマシンによってマウントされているうちに RFS を停止しようとした場合、あるいは現在リソースをマウントしているリモートマシンを除外したクライアントリストで、リソースを再公開しようとした場合に発生します。
このエラーの記号名は、ESRMNT、errno=69 です。
NFS クライアントが開いたファイルまたはディレクトリが、サーバー上で削除されたかまたは置き換えられました。
このファイルを編集していた場合は、代わりに、ローカルファイルシステムに書き込みます。ファイルシステムをマウントし直すか、または古いファイルハンドルを参照するクライアントプロセスをシャットダウンします。このいずれでも解決しない場合は、システムをリブートします。
元の v ノードは無効になりました。このエラーを解決する唯一の方法は、NFS サーバーとクライアントにファイルハンドルをもう一度ネゴシエーションさせることです。
このエラーの記号名は、ESTALE、errno=151 です。
「late initialization error」を参照してください。
このメッセージは、NFS 状態監視デーモンである statd(1M) によって表示されます。statd(1M) は、NFS ロックデーモン lockd(1M) にクラッシュ修復サービスを提供します。このメッセージは、statd が古い参照内容を /var/statmon/sm および /var/statmon/sm.bak ディレクトリに残していることを示します。ユーザーが hosts データベース内のホストを削除または変更した後、statd(1M) がこれらのディレクトリのファイルを正しくパージしていない可能性があります。その場合は、存在しないホストと通信しようとします。
variable の部分に示されたファイル (variable にはホスト名が入ります) を /var/statmon/sm と /var/statmon/sm.bak の両方のディレクトリから削除します。次に、statd(1M) デーモンを終了してから再起動します。それでもこのメッセージが表示される場合は、lockd(1M) も終了してから再起動します。これでもうまくいかない場合は、マシンをリブートしてください。
このメッセージは、ユーザーがマシン間で、rcp(1) によるリモートコピーまたは rsh(1) によるリモートシェルを行おうとしたときに、リモートの .cshrc ファイルに stty(1) コマンドがある場合に表示されます。このエラーが発生すると、rcp(1) コマンドまたは rsh(1) コマンドは失敗します。
この問題を解決するには、stty(1) コマンドをユーザーの .login (またはこれに相当する) ファイルに移動します。または、シェルが対話型の場合にのみ stty(1) コマンドを実行するように .cshrc を変更します。次のテストを行うこともできます。
if ($?prompt) stty ... |
rcp(1) と rsh(1) の各コマンドは、ソケットを使用して接続します。ソケットは、stty(1) で実行される TCGETS ioctl には対応していません。
このメッセージは、誰かが、ルート用のデフォルトのログインシェルを、システムに存在しないプログラムに変更したことを示します。たとえば、/etc/passwd 内の最後のコロンで区切られたフィールドが /sbin/sh から存在しない /usr/bin/bash に変更された可能性があります。または、行末に余分な空白が付けられている可能性があります。結果的に、root としてログインしたり、ユーザーを root に切り替えたりすることができなくなるため、この問題を直接解決できません。
唯一の解決方法は、別の媒体からシステムをリブートして、パスワードファイルを編集し、この問題を解消することです。sync(1M) を何度か呼び出してから、Stop-A と入力するかまたはリセットボタンを押してマシンを停止します。プロンプトで boot cdrom -s と入力して、CD-ROM、ネットワーク、またはフロッピーディスクからシングルユーザーとしてリブートします。
システムが立ち上がって # プロンプトが表示されたら、下記に示すような mount(1M) コマンドを使用して、オリジナルの root パーティションに対応するデバイスをマウントします。次に、新たにマウントしたシステムのパスワードファイルでエディタを実行します (端末のサポートがない場合は ed(1) を使用します)。
# mount /dev/dsk/c0t3d0s0 /mnt # ed /mnt/etc/passwd |
「No shell」の障害が発生しないようにするには、パスワードファイルを編集する際には admintool または /usr/ucb/vipw を使用するように習慣付けます。これらのツールを使用すると、システムが使用不能になるようなパスワードエントリに変更することが難しくなります。
login の後に示されたユーザーがスーパーユーザーになろうとしましたが、入力したパスワードが違っていました。
ユーザーが root のパスワードを知っていると考えられる場合は、正しいパスワードを入力するまで待ちます。パスワードを知っているはずがない場合は、スーパーユーザーになろうとしている理由を問い合わせます。
login の後に示されたユーザーが、root のパスワードを入力してスーパーユーザーになりました。
ユーザーが root のパスワードを知っていると考えられる場合、このメッセージは情報を表示しているだけです。パスワードを知っているはずがない場合は、直ちにこのパスワードを変更し、パスワードを入手した方法をユーザーに問い合わせます。
SunPC 4.1 と 102924 ジャンボパッチをインストールして、(root 以外の) ユーザーが SunPC を実行しようとしたところ、次のエラーメッセージが表示されました。
SunPC may NOT run correctly as root. Please run in user mode. SunPC script is exiting |
$ /usr/bin/id uid=33650(gruff) gid=0(root) |
ユーザーの一次グループを、10 などの別のグループに変更し、ユーザーが root のグループに属している必要がある場合は、root グループをユーザーの二次グループのリストに追加します。
このメッセージは、ファイルシステムの整合性を保つために、システムがダウンする前にカーネルがスーパーブロックを更新していることを示します。このメッセージは、halt(1M) コマンドまたは reboot(1M) コマンドの後に表示されます。また、システムパニックの後に表示されることもありますが、その場合は、システムに損傷データがある可能性があります。
マシンの停止、または再起動直後はそのままにしておいてください。このメッセージは正常です。システムパニックの場合は、パニックメッセージを調べてください。問題点の診断について、システムベンダの協力を得られるか問い合わせてください。ベンダに協力を得られる場合は、パニックの説明ができるように、システムをパニック状態のままにしておくか、または障害を再現できるようにしてください。
メッセージ内の 3 つのドットの後に数字が表示されることがありますが、この数字は、書き出されるダーティーページ数を示します。カッコ内の数字は、システムのビジーバッファーの推定数を示します。
システムのリブート中、このメッセージが表示されて、ブートがハングしたようです。syslogd(1M) サービスの開始後、システムは /etc/rc2.d/S75cron を実行します。/etc/rc2.d/S75cron は次に ps(1) を呼び出します。システムが突然クラッシュすると、/dev/bd.off がどこにもリンクされていない状態になることがあり、ps(1) コマンドがハングすることがあります。
(たとえば boot -s によって) シングルユーザーとしてリブートし、ls -l /dev/bd* を実行して、これが原因であるかどうかを判断します。原因である場合は、/dev/bd.off を削除してから、bdconfig off を実行するか、または -r (再構成) オプションを付けてリブートします。
これは、ps(1) のハング原因として最も報告が多い状態です。
システムが自動的にリブートし、その後、メッセージファイルに「System booting after fatal error FATAL」が含まれます。
このメッセージは、システムがハードウェアエラーを検出したあとのリブート中に出力されます。以下の状況により、この応答が返されることがあります。UPA アドレスのパリティエラー、マスター待ち行列のオーバーフロー、DTAG パリティエラー、E-Cache タグのパリティエラー、一貫性のエラーなどがあります。
prtdiag(1M) は、失敗したハードウェアコンポーネントの特定に使用すると便利です。エラーは、CPU モジュールまたはシステムボードが不良であることを示します。
Networker でクライアントをバックアップしようとして、次のエラーになりました。
* heaven.com:/export/heaven2 save: SYSTEM error, Arg list too long * heaven.com:/export/heaven2 save: Cannot open save session with heaven.com * heaven.com:/export/heaven3 1 retry attempted * heaven.com:/export/heaven3 save: SYSTEM error, Arg list too long * heaven.com:/export/heaven3 save: Cannot open save session with heaven.com |
このようなエラーは、Solstice バックアップバージョン 5.0.1 未満の 2 G バイトを超えるインデックスファイル (/nsc/index/clientname) が原因です。5.0.1 では、インデックスはセグメント化されているのでこのエラーは問題になりません。Solstice バックアップのどのバージョンでも、クライアントインデックスの破壊が原因でこのエラーになることがあります。その場合は、次のコマンドで問題を解決できる場合があります。
# nsrck -F clientname |
4.1.3C の SBUS カードのために、システムがフリーズしました。
ユーザーがシステムを起動すると、ブートメッセージ root on、swap on、および dump on の後にハングします。システムがこれらのメッセージを表示した後、LED が点滅し、システムがハングします。
これは、以前に fsck を実行した際に /dev ディレクトリの下のデバイスが削除されたことが原因で発生します。/dev/console デバイスを探し、ない場合はこのデバイスを作成します。
「late initialization error」を参照してください。