tmty.jp

ここのデザインを変更がてら、自サイト(tmty.jp) 配下のコンテンツを巡回していたら、trac がエラーを吐いていた:

Python Traceback

Traceback (most recent call last):
File “/home/****/local/lib/python2.4/site-packages/trac/web/main.py”, line 406, in dispatch_request
dispatcher.dispatch(req)
File “/home/****/local/lib/python2.4/site-packages/trac/web/main.py”, line 191, in dispatch
chosen_handler = self._pre_process_request(req, chosen_handler)
File “/home/****/local/lib/python2.4/site-packages/trac/web/main.py”, line 263, in _pre_process_request
chosen_handler = f.pre_process_request(req, chosen_handler)
File “/home/****/local/lib/python2.4/site-packages/trac/versioncontrol/api.py”, line 73, in pre_process_request
self.get_repository(req.authname).sync()
File “/home/****/local/lib/python2.4/site-packages/trac/versioncontrol/api.py”, line 91, in get_repository
raise TracError(’Unsupported version control system “%s”. ‘
TracError: Unsupported version control system “svn”. Check that the Python bindings for “svn” are correctly installed.

これまで問題なかったのに、svn が Unsupported とか言い出してるのは妙だ。python が svn 連携に失敗しているのかな？
試しに、python のコマンドライン実行で確認してみる。

$ python -c “from svn import client”
略)
… Shared object “libintl.so.6″ not found, required by “_client.so”

なんかいっぱいエラーが出たが、Shared object が無いって、なんで今更突然こんなエラーが出るようになっちゃったんだろ。最近サーバ設定いじった記憶ないし.. と、さくらのニュースアーカイブを見に行ってみたら、メンテナンス通知が出てた:

平素はさくらインターネットをご利用いただき、誠にありがとうございます。
さくらのレンタルサーバサービスにおきまして、サービスの安全性の向上を
目的とした、OS のバージョンアップを実施いたします。
ご迷惑をおかけしますが、ご協力お願いいたします。
中略)
1/15(火) www731 〜 www740.sakura.ne.jp
1/16(水) www741 〜 www755.sakura.ne.jp
1/18(金) www756 〜 www770.sakura.ne.jp
中略)
主な変更:

OS FreeBSD 4.10 → 6.1
後略)

うお、もろ該当サーバに入ってた。これは影響でかいだろー。知らなかった.. サーバメンテの通知は、ちゃんとチェックしとかなきゃダメっすな。(でも、メールとかでリマインドしてくれても良いのになー。掲載から作業日程短すぎな気がする。)

4.10 => 6.1 での細かい変更点までは追ってないが、恐らくユーザインストールしたアプリ周りは、ほぼ reconfigure/rebuild が必要になるだろう。ということで、再設定開始。さくらのレンタルサーバでは、python は最初から入ってる(ユーザインストールしたものではない)ので、subversion 周りの reconfigure から開始。設定は覚えてなかったので、config.log で configure オプションを確認してから、SWIG-1.3.21 を $ ./configure && make && make install 、続いて、subversion-1.2.3 を $ ./configure && make && make install && make swig-py && make install-swg-py と。あと、念のため、svn-python/svn 以下の symlink を貼り直した。

とりあえず、こんだけで $ python -c “from svn import client” が通り、trac も動くようになった。

が、1/21 5:04 現在、機種情報検索サービス(rails環境)が復旧できてない。ruby/gem 周りも一通り再設定して、アプリ自体は script/console 環境下で問題なく動いているんだが、Web 経由で DB アクセスが発生するようなリクエストを投げると 500 になっちゃう。apache のエラーログって拾えないのかな？rails のログにはエラーが落ちてないんだが、DB アクセスしない範囲のリクエストは正常にさばけてるるっぽい。CGI 経由で DB に行ったときだけ利いてくる設定って.. どこだ？apache ログが拾えないと切り分けできないかな？うーん.. と、ここで力尽きたので、続きはまた今度。求む識者。

(2008/01/25 追記) その後.. とりあえず解決:

ruby を再設定したり、gem も入れ直したり、ついでだから rails-2.0.2 で試してみたり、その他諸々、いろいろ試行してみるも動作せず。ふと、rails レベルでログをもっと出せんもんかと、${RAILS_HOME}/config/environment.rb でアプリの動作モードを production から development に落としてみた。

そしたら、なぜか、これで動いた。なに〜。

とりあえず解決したんだが、これでどうして動くようになったのか分からん。キャッシュ動作周りが悪さをしてたのか？でも production.rb で config.cache_classes = false は試したんだけどな.. とか考えながら、${RAILS_HOME}/config/environments 以下の development.rb と production.rb を見比べながら、設定をひとつずつ入れ替えてみる。そしたら、どうやら、次の一行があれば production でもちゃんと動く事がわかった。

名前からして、「これは関係ないだろう」と思わざるを得ない項目。でも、これが無いと 500 Internal Server Error 。false 設定しててもダメ。true 設定してある必要がある。

んじゃ、こいつが何に効いてるんだと、rails のソースを追ってみる。rails-1.2.3/lib/initializer.rb で発見。

<br /> # Sets the +BREAKPOINT_SERVER_PORT+ if Configuration#breakpoint_server<br /> # is true.<br /> def initialize_breakpoints<br /> silence_warnings { Object.const_set(”BREAKPOINT_SERVER_PORT”, 42531) if configuration.breakpoint_server }<br /> end<br />

何これ。ほんとにソレ用のポート設定してるだけに見えるんだけど。

で、もう追う気無くした。動いたからいいんだけどさ。謎。ググってみたら、rails-2.x 以降で breakpoint_server が deprecated and has no effect だから、もう使ってくれるな、という話がいっぱい。なんなんだろ。誰か教えて。

関連していそうなエントリ:

• djangoを試してみた