Path: sran265!katsu From: katsu@sran14.sra.co.jp (WATANABE katsuhiro) Message-ID: Date: 24 Aug 92 22:40:26 Organization: Software Research Associates, Inc.,Japan In-reply-to: m-ikeda@win.juice.or.jp's message of 23 Aug 92 06:39:39 GMT Newsgroups: fj.misc, fj.news.adm Followup-To: fj.news.adm Subject: Re: About expire program for news system (In Japanese/Kanji) Distribution: fj References: <131@win.juice.or.jp> fj.misc ではなく、それらしい場所に移りましょう。(Followup-To: に注意) 記事 <131@win.juice.or.jp> で m-ikeda@win.juice.or.jp (Makoto Ikeda) さんいはく > news expire: dbm store failed > > というerrlogが残り一向にexpireできません。 > > コマンドは > expire -e30 -n alt  message-id を key とし、それに対応するヒストリーエントリーの history ファイル内での位置を contents とする組が dbm で管理されて いるわけですが、この組を新たに登録できなかったということですね。 (肝心の、これを起こした真の原因には、いろいろなものがあると思います)  expire に -v 6 フラグを付けて実行してみると、異常終了直前の処理を もとに、より詳しく状況がわかるかもしれません。  実は最近ヒストリーの再構築の際に「dbm store failed」を体験してます。  fj.ai に、message-id が 255 文字もある記事が2つ3つ届いていました。 (どこかのサイトで、メールを使って投稿する機構が問題を起こしていたと 想像してます。)その状況でヒストリーを再構築した際、この長い message-id を key とするヒストリーエントリーを登録しようとして dbm ライブラリが失敗し、expire が件のメッセージとともに異常終了して いたのでした。  古いヒストリーファイルから message-id が異常に長い記事を捜し出し、 そうした記事のファイルを全て rm することで解決をみています。  ちなみに上のような経験をしたのは、DBM を DBZ で置き換えた BNEWS のシステムでした。DBM では key + contents の最大長が 1024 でなければならないようですが、DBZ では key の最大長が 254という 制限になっていると思います。 ----____----____ 渡邊克宏@SRA