Ridoc Document Routerの無限ループ
by tan on 8月.31, 2010, under パソコン
先日から調子の悪いRidoc Document Routerサーバをだましだまし使っていたが、昨夜からまた止まっていたようでＦＡＸが受信したデータをサーバに送れずにいた。
ところがサーバ自体のＯＳは起動していたようでpingにきちんと応答を返してくる。
現場のユーザーからもＦＡＸが使えないという問い合わせも無いので、現場に行って確認してみると確かにＯＳは起動している。
クライアントＰＣからRidoc Deskで接続することも出来、配信されたデータを見ることも出来るが、ＦＡＸ機からの接続がうまく行かない様でネットワークエラーの状態が続いていて、受信したFAXデータをサーバに送れないためメモリ残量が20%を下回ってしまった。
受信したFAXを紙に印刷してしまえばメモリを開放することが出来るのだが、悪いことに紙詰まりを起こしていて印刷が出来ない状態。
とりあえず受信したFAXを印刷するために詰まった用紙を取り除き、用紙を補給してなんとか全てを印刷してメモリは開放できたが、相変わらずサーバにはデータを送ることが出来ない。
配信管理ツールでIO機器設定を見てみると何故か同じFAXが2つ登録されていたので、片方を削除して念のためFAX機の設定で配信サーバのアドレスを確認すると案の定クリアされていた。
クリアされていた配信サーバのアドレスを正しく設定しなおすとネットワークエラーは解消されたので、試しに一枚スキャンしてサーバに送ってみると、FAX機からは正常に送られたように見えた。
ところが、サーバの配信ログを見ると全く配信された記録が見当たらず、クライアントからも見えない。
RicohのRidoc Document Routerが受信したドキュメントを処理できずに無限ループに陥ってしまったようだ。
どうも強制的にサーバが停止した時にデータやファイルの整合性が狂ってしまったらしい。
またループに陥ったせいで配信管理ツールからサービスの停止を試みてもサービスが停止しないので、タスクマネージャからDds.exeのプロセスを停止することでようやくサービス停止の状態になった。
かなり以前にも似たようなことがあり、その時はRicohの担当者の方のアドバイスを受けながら復旧させたような記憶があるが、どのようにして復旧させたかが今現在判らない（汗）。
明日にでも再度Ricohに問い合わせてみるかぁ、、、、、、なんかファイルを削除したような気がするんだよなぁ、、、、、
9月 1st, 2010 on 4:21 PM
[…] 昨日書いた「Ridoc Document Routerの無限ループ」はなんとか解決した。 今日の朝Ricohに問い合わせたところ、複数の原因が考えられるがとりあえず出来ることを教えてもらえたので、現場に行ってやってみた。 ループに陥る原因としては、昨日も書いたが受信したデータを処理中にサーバがダウンしたために、処理が中途半端になったデータがあることや、処理するデータが大量にあるために処理に時間がかかり一見無限ループに陥ってしまったように見える場合もあるとのこと（いや、それは判りますがね）。 他には実行ファイルそのもの（Dds.exe）の破損も考えられるということだったが、今回は敢えて考えないことにした。 今回のはIO機器から送ったデータがA4一枚分しか無いことや、サーバを何度再起動しても変化が無いことからデータ量が多過ぎるということが原因とは思えず、やはり処理途中の中途半端な状態のデータがある為に配信サービスのプロセスが処理を終了できないでいると考えた。 そこで処理途中の中途半端な状態のデータを捨てることで正常な状態に復帰するのではないか（いや、「復帰して欲しい」が正解か）と思い、IO機器から送られたデータがどのように処理されるかを教えて貰い、正常に処理がされていればデータが存在しないはずのフォルダにあるファイルを消すことにした。 以降のフォルダ名の先頭の「RidocCab」はインストール時に指定したデータフォルダ名を指すので、ドライブレターやフォルダ名はその指定したものになる(例えばデータフォルダを「C:Ricoh-data」とした場合は「C:Ricoh-dataFtpRoot”機器NO”」のようになる）。 IO機器から送られたデータは、最初に「RidocCabFtpRoot”機器NO”」に入り、処理に伴い「RidocCabDRSpoolCompose」→「RidocCabcabinetWG_Root”各フォルダ”」の順に移動して行くので、最初の2つのフォルダにはファイルは残らない（筈）。 ＃ここで言う”機器NO”とは、各IO機器が持っている固有のNoで、配信管理ツールでFAX配信ログやスキャナー配信ログの”配信元機器”に表示されるNOのこと。 なので、「RidocCabFtpRoot”機器NO”」及び「RidocCabDRSpoolCompose」内のファイルをフォルダごと消すことにした。 まず最初に作業中にIO機器からのデータを受信しないように、タスクマネージャを使ってDds.exeの動作を止めて配信サービスを終了させた（配信管理ツールからでは停止できなかったため）。 次に念のため「RidocCabDRSpool」以下のフォルダとファイルを全て他の場所にバックアップとしてコピーした（幸い「RidocCabFtpRoot”機器NO”」以下にはファイルは無かったので「RidocCabDRSpool」以下だけで済んだ）。 その後「RidocCabDRSpool」以下のフォルダ（「Compose」「Entries」「Error」「JobList」）内のファイルとフォルダを全て削除した。 削除が完了したところでサーバを再起動し、起動後にタスクマネージャで負荷を見たところ、それまでは100%だったのがDds.exeが動作している状態でも数%まで下がっていたので、試しにFAX機からデータを送ったところ無事に指定したフォルダにデータが格納された。 これでなんとかIO機器からのデータを正常に処理することが可能になったが、サーバ自体はHDDにエラーがあって動作が不安定のままなので、早急にHDDを交換して再構築しなくてはならない。 HDDを交換して「EASEUS Drive Copy」を使ってディスク全体をコピーするつもりだけど、エラーのあるHDDを正しくコピーすること出来るのかな？ […]