[an error occurred while processing this directive]

(Illustration by Gaich Muramatsu)

Coda File System

Home Downloads
(インフォサイエンス)
Bugs Documentation
News Mailing lists FAQ Research
 
---------

次へ 戻る コンテンツ


5. トラブルシューティング

Coda のファイルシステムはまだ開発途上で、クライアントとサーバをクラッシュさせるようなバグが確実にあります。しかし、ユーザが気付く多くの問題は、良く知られた NFS か SMB ネットワークのファイルシステムと Coda のファイルシステムを比較するような、解釈の違いに関するものです。

このセクションでは問題となるケースを確認するためにいくつかログを出して下さい。問題の原因が見つからなくても Coda のログから集めた情報で、coda メーリングリスト <coda-discuss@coda.cs.cmu.edu> の人々では、問題の解決をする手ががりになります。

より一般的な問題についての詳細があります。このセクションの終わりで、デバッグのテクニックを必要とするものが取り組まれています。これは問題を簡単にするために、開発者の役に立ちます。

最後に、Windows95 で生じる問題の解決法のセクションがあり、Coda の関連スタッフだけです!

5.1 トラブルシューティングの基本

ほとんどの問題は解決済みか、少なくともクライアントとサーバから出るログを見て理解することができます。問題の基を探る最初の方法は、ログファイルに tail -f をすることです。

coda のクライアントとサーバがクラッシュすると`dump core'をしませんが、スリープしてデバッガをアタッチすることに気を付けてください。結果として、クラッシュしたクライアント、またはサーバはまだ ps auxwww の出力に現われます。ファイルサービスの欠けた組み合わせで、ログファイルにエラーメッセージがあれば、何が悪いのかわかります。

クライアントのデバッグ出力

サーバログ

5.2 クライアントの問題

クライアントは testserver.coda.cs.cmu.edu には接続しません

最初にクライアントをセットアップした時、CMU のテストサーバに接続できませんが、それには二つの理由があります。 coda の古いリリースを走らせているかもしれないので、最新のリリースを coda のウェブサイトで確認してください。

他によくある理由としては、外部への接続、udp のトラフィックだけを許可して他はブロックするような、ファイアウォールの背後にサイトがある場合です。 ファイアウォール外部のマシンで coda を試すか、自身のサーバをセットアップしてください。

3つ目の理由としては、メインテナンスやアップグレードのためにテストサーバがダウンしているのかもしれません。これはめったに起こりませんが、 作動しているのかどうか、cmon を使ってどんな風に走っているのか確認してください。

cmon testserver.cs.cmu.edu:100

Venus が立ち上がりますが、RootVolume が見つからないという表示がされる

先に示した理由の全てが原因になり得ます。/etc/services ファイルが正しくない可能性もあります。必要なエントリは:

# Iana allocated Coda filesystem port numbers
rpc2portmap     369/tcp    
rpc2portmap     369/udp    # Coda portmapper
codaauth2       370/tcp    
codaauth2       370/udp    # Coda authentication server

venus           2430/tcp   # codacon port
venus           2430/udp   # Venus callback/wbc interface 
venus-se        2431/tcp   # tcp side effects
venus-se        2431/udp   # udp sftp side effect
codasrv         2432/tcp   # not used
codasrv         2432/udp   # server port
codasrv-se      2433/tcp   # tcp side effects
codasrv-se      2433/udp   # udp sftp side effect

ファイルにアクセスしようとすると Connection timed out (ETIMEDOUT) が返ってくる

Connection timed out エラーが出る主な理由は、ファイルが配置されたボリュームがサーバから切断されたからです。 しかし、クライアントが書き込み−切断モードにある場合に、ファイルに書き込みを行おうとすると発生します。 詳しくは ボリュームの切断/ボリュームの書き込み−切断 を見てください。

^C./ をつかわないと、コマンドがリターンしない

コマンドがハンギングすると venus はクラッシュしそうになります。/usr/coda/etc/console/usr/coda/venus.cache/venus.log を確認してください。

再起動に失敗する Venus

もし venus が venus.log/dev/cfs0 を開けないことについて文句を言うのなら、それは /coda がまだマウントされていないせいです。

# umount /coda

他の理由としては、venus の他のコピーが作業中なので venus がネットワークソケットを開くことができないからです。この場合には RPC2_CommInit が失敗した状態のメッセージを venus.log に出します。

Venus が起動しない

カーネルのモジュールが正しくないからです。手動でモジュールを挿入することでテストして、有効なモジュールを一覧します。 `coda' はそのリストに現われるはずです。そうでなければ新しいモジュールを再インストール(あるいは再コンパイル)することです。

# depmod -a
# insmod coda.o
# lsmod
Module                  Size  Used by
coda                   50488   2

カーネルモジュールがエラーなしでロードできるなら、venus.log を確認してください。 `Cannot get rootvolume name' のメッセージはサーバの設定ミスか、codasrv/codasrv-se のポートが、次のエントリにあるべき /etc/services で定義されていないからです。必要とされるエントリは上を見てください。

切断して、Venus が起動しない

/etc/hosts にサーバのホスト名を置いてください。

切断の間、トークンが取れない

バージョン 5.2 まではそうでした。この機能を追加します。

貯蔵が働きません

バージョン 5.0 以降の Coda であることを確認してください。貯蔵する前にそれを確認してください:

5.3 サーバの問題

サーバがクラッシュして"AllocViaWrapAround"についてのメッセージを表示する

これはレゾリューション・ログが一杯になると発生します。SrvLog ファイルでは、ボリュームが影響を受けたのがわかり、そのボリューム id を記録します(このためには SCM で /vice/vol/VRList を調べる必要があります)。死んだ(ゾンビ化した)サーバを殺して、再起動します。その時にすることは:

filcon isolate -s "this server" # to prevent clients from again 
                                # overwriting the log
volutil setlogparms "volid" reson 4 logsize 16384
filcon clear -s "this server"

"途方もない"ことをしない限り、16k でたくさんです。

プログラムをサルベージするせいで、サーバが起動しない

もしこうなったら、いくつかの選択肢があります。サーバがサルベージの間にクラッシュすると、再試行の時に立ち上がらず、ダメージのあるボリュームを交換するか、そのボリュームにアタッチしないかの、どちらかを行わなければなりません。

ボリュームにアタッチしないようにするには、以下です。SrvLog でダメージのあるボリュームのボリューム id を探してください。/vice/vol/skipsalvage というファイルを作ってください:

1
0xdd000123

ここで 1 は、単一のボリュームがスキップされて、0xdd000123 がアタッチされない複製のボリューム id であることを示します。 もしこのボリュームが複製されたボリュームで、全てオフラインで複製になるなら、そうしないとクライアントが混乱するからです。

norton でボリュームを修復することもできます。norton の実行方法は:

norton LOG DATA DATA-SIZE
このパラメータは /vice/srv.conf にあります。

Norton のマニュアルページには norton の操作についての詳細があります。オンラインのガイダンスも利用できます。

注:

  1. しばしばコラプションが複製されます。もしサーバがクラッシュしているのを発見して、ボリュームをサルベージしないと、複製も同じ運命になります: テープを使わなければならないかもしれません(ちゃんとテープを作ってますか?)。したがって、最初のコピーは利用できる状態にある複製から取って、それからサルベージするために、リペアしたりスキップしたりします。
  2. ボリュームとその最新のクローンの両方を(バックアップの間に生じる)オフラインで取ることがよくあるので、ボリュームのコラプションはクローンによって受け継がれます。
  3. もしボリュームの複製にコラプトを発見したら、単に複製を置き換えることはしないでください。ボリュームのデータベースがコラプトしているのです。 新しい複製ボリュームを作って、まともな複製からデータをコピーする方が良いでしょう(まともじゃない複製ではサーバがダウンします)。

どうやってテープからバックアップをレストアしますか

火曜日に email フォルダをなくしました - moose:braam.life ボリューム全体は moose サーバでコラプトして、サルベージしていません。どうやったら元に戻せますか。

まず、moose.braam.life.0.backup をマウントしようとしましたが、これもコラプトしています。

/vice/vol/VRList にある SCM では、ボリュームに対して複製されたボリューム番号 f0000427ce000011 (ficitious) がありました。

バックアップ・コントローラである bison に root でログインしました。/vice/backuplogs/backuplog.DATE で火曜日の朝にバックアップログを読んで、8 月 31 日 に成長するダンプがまともであることがわかりました。ログの最後に、/backup (単なるシムリンク) と、実際のファイルのあるスプールディレクトリとして /backup2 下にダンプされたものとして f0000427.ce000011 があるのを見つけました。バックアップ・ログはどのようにテープを正しい場所に動かして、レストアを起動したかを示します:

     cd /backup2
     mt -f /dev/nst0 rewind
     restore -b 500 -f /dev/nst0 -s 3 -i

-s 3 オプションは、バックアップがリストアされる /backup[123] ボリュームによって変わります。これはレストアのコマンドを呼び出します。ファイルを追加して取り出すのに役立ちます。ファイルが戻される前に、ちょっと間があります。レストア・プロンプト:

     restore> cd 31Aug1998
     restore> add viotti.coda.cs.cmu.edu-f0000427.ce000011
     restore> extract
     Specify volume #: 1
<verb>

/vice/db/dumplist では、最新のフル・バックアップが 8 月 28 日 でした。マシン・ルームへ行って、テープを入れました(最新のテープは bison 上です)。この時間 f0000427.ce000011 は /backup3 にある 200MB ファイル(最新のフル・ダンプ)。上のようにファイルを展開します。それから二つのダンプをマージします:


<verb>
     merge /restore/peter.mail /backup2/28Aug1998/f0000427.ce000011 \
           /backup3/31Aug1998/f0000427.ce000011

これは /restore/peter.mail の作成に 1、2 分かかります。今必要なのはボリュームに対してアップロードすることだけです:

     volutil -h moose restore /restore/peter.mail /vicepa vio:braam.mail.restored

ボリューム・データベースをアップデートするために、SCM に戻ります:

     bldvldb.sh viotti

レストアされたボリュームをマウントすることができます:

     cfs mkm restored-mail vio:braam.mail.restored

cpio か tar を使って読み書きするボリュームにそれをコピーします。

createvol_rep は RPC2_NOBINDING を知らせます

ボリュームを作ろうとすると、createvol_rep は RPC2_NOBINDING を知らせます。これはサーバがまだ接続を受け入れていないことを示しています。

ある程度時間がかかる起動時に、サーバが fsck をしているのを /vice/srv/SrvLog で見ると役に立ちます。サーバが SrvLog に `Fileserver Started' だけをログすると、入ってくる接続を受け入れます。

他の理由としては、受け入れるネットワークのポートから新しいサーバをブロックするような古いサーバがまだ活躍していることです。

rpc2portmap/auth2 ログには RPC2_DUPLICATESERVER があります

プロセスのいくつかは、rpc2portmap か auth2 が得ようとしている UDP ポートの解放です。ほとんどの場合、これは rpc2portmap か auth2 のコピーをすでに動かしています。問題の走っているプログラムのコピーを殺して、されを再起動してください。

/vice/db でファイルをアップデートした後すぐにサーバがクラッシュした

サーバはインコンシステントや、まともじゃないデータファイルを与えられた時にクラッシュします。SCM とクラッシュしたマシンで updateclntupdatesrv の両方が走っているかどうかを確認するべきです。殺して再起動します。その時、codasrv を再起動して、それが立ち上がります。

ユーザ認証ができない、あるいは作ったボリュームがマウントされない。

auth2、updateclnt、updatesrv が全てのファイルサーバで走っているかどうか確認してださい。起こりうるエラーについて、ログファイルを確認してください。

5.4 切断

よくある問題としては、"自発的でない"切断の結果生じる、解釈の違いに関するものです。このセクションでは、なぜボリュームが切断、あるいは書き込み切断になるのか、その背景についても説明します。そして、再接続の方法についても。

ボリュームが完全に切断される。

coda のクライアントがアクセス可能なサーバからボリュームを切断する理由がいくつかあります。

ボリュームは書き込み切断です。

書き込み切断操作 は、このボリューム・ステートを示すための 弱い接続モードと同じように使われて、事実上同じです。これは、クライアントがサーバとの接続が弱いことに気付く特別な状態で、その結果、弱い接続モードでボリュームを関連付けます。弱い接続のボリュームは遅いネットワークの接続での待機を減らす意味で、サーバへの書き込みを後回しにします。読み込み操作は、完全な接続モードとしてローカル・キャッシュとサーバによってサービスされます。このモードの操作も書き込み切断操作と呼ばれます。

書き込み操作は、裏面では事実上連続的な再構成(trickle-reintegration)です。だからこのモードは認証されたユーザを必要とし、実行できるファイルのコンフリクトには機会を与えます。以下の点は書き込み切断操作の理由です。

5.5 進んだトラブル・シューティング

rpc2tcpdump

rpc2tcpdump はレギュラーの tcpdump で、rpc2 プロトコルヘッダを決定するために修正されます。これは、なぜプログラムが動かないかを分析するのに便利なツールです。

venus と coda サーバ間の全てのトラフィックは、以下のコマンドを使って見ることができます。

# tcpdump -s120 -Trpc2 port venus or port venus-se

clog で問題を確認するのは、例えば、トークンを得ようとしているのはどのサーバか、です。

# tcpdump -s120 -Trpc2 port codaauth

gdb のデバッグ

RVM を使ってプログラムのデバッグを可能にするための、coda と関連するほとんどのアプリケーションは、なにかがうまくいかない時にエンドレス・スリープになります。ログ(venus.logSrvLog)にあるプロセス id を表示して、ユーザはクラッシュしたものにデバッガをアタッチできますが、まだ走っているプログラムです。

# gdb /usr/sbin/venus `pidof venus`

これはスタックのバックトレース(場所)の入手を可能にして、特定のスタック・フレーム(frame <x>)に向かうか、変数のコンテンツ(print <varname>)を調べます。バイナリが最初に構築された場所と同じ所で coda のソースをインストールして、list コマンドを使ってデバッガ内部からコードのフラグメントの周辺をみることができます。

RedHat Linux rpm を使っているなら、coda ソース rpm ファイルをインストールすることによって、正しい場所にソースをインストールすることができます。

# rpm -i coda-x.x.x.src.rpm
# rpm -bp /usr/src/redhat/SPECS/coda.spec

他のプラットフォーム上では、バックトレースで記録されたパスを見て、正しい場所でソースの tar アーカイブを展開してください。

(gdb) where
#0  CommInit () at /usr/local/src/coda-4.6.5/coda-src/venus/comm.cc:175
#1  0x80fa8c3 in main (argc=1, argv=0xbffffda4)
    at /usr/local/src/coda-4.6.5/coda-src/venus/venus.cc:168
(gdb) quit
# cd /usr/local/src
# tar -xvzf coda-4.6.5.tgz

5.6 Windows 95 のトラブル・シューティング

よくある問題

Coda をマウントできない

relay.exevenus.exe が走っているときにだけ coda をマウントすることが可能です。venus がメッセージ

venus starting...
をプリントする前に mount.exe n: を実行しないでください。

インストールでは、アクティブでない時に Venus が走っている DPMI DOS エクステンダ Window がサスペンドすることがあります。なぜなら Venus は mount.exe n: のコールを受け取り、DOS Window の設定をチェックします。window のプロパティ>その他>背景>常にサスペンド、の選択を外します。もし選択が外れていれば、選択して、選択を外すことを試してください。

Windows95 をシャットダウンできない

Venus と Relay の DOS Window 設定を確認してください。プロパティ>その他>終了のチェックを外してください。

Windows 95 を再起動できなくて、Coda でロードされた VXDs のせいのように見えます

ブート時に F8 を押して DOS モードでシステムをブートしてください。windows のディレクトリに移動して、edit system.ini を入力してください。 セクション [enh386] でエントリを見ることができます。

device=c:\usr\coda\bin\mmap.vxd 
device=c:\usr\coda\bin\mcstub.vxd

行の先頭で;を付けてコメントアウトしてください。そして Windows を再起動します。

なぜ relay.exe がクラッシュしたのか、どうすればわかりますか

relay.exe は、ファイルシステムドライバから venus.exe へ、またはその逆のリクエストを手渡す、とても小さなプログラムです。 relay.exe のクラッシュは、たいがいバッファのオーバーフローかヌル・ポインタをリフェレンスするせいです。relay.exe は relay が開始されたディレクトリにある relay.log というファイルにデバッグ情報を示します。

relay.exe がクラッシュすると、ファイルシステムドライバはまだロードされます。relay.exe を再起動してください。unmount.exe という、システムをアンマウントすることがほとんど不可能になります。

なぜ venus.exe がクラッシュしたか、どうやったらわかるでしょう

venus のトラブル・シューティングを見てください。これが発生したとき、venus の再起動が可能になります。ファイルシステムがアンマウントされている必要はありません。

何が起こったのか、どうやったらわかりますか

c:\vxd.log ファイルを見てください。ファイルシステム・ドライバ codadev.vxd は、このファイルに全てのリクエストについてのリクエストと答えを示します。relay.log でこれと一致するリクエスト番号を確認してください。

ネットワークとエクスプローラのブロックで走っているマシンがフックします

Venus は短いタイムアウトの後、切断モードにスイッチします。後でうまく動くはずです。そうでなければ、エクスプローラの'ネットワークの接続'のセットアップがあるかどうか(例えば samba のドライブ)確認してください。'ネットワークの接続'はシステムをブロックして、その時ネットワークは使えません。

制限


次へ 戻る コンテンツ

---------
詳しくはメールで

このページの情報に関わる、ご質問、お問い合わせは、 japache@infoscience.co.jpまで。
Coda ホームページ