あり得ないミスなのだがこのサーバーをホスティングしているXenのディスクイメージ(Domain-0上のフラットファイル）をうっかり削除してしまった。ちなみにこういう人為的なミスに対してはRAIDは何の役にもたたない。こんな致命的なミスは学生時代に自分のホームディレクトリーを”rm -rf”で消した時以来である。その時は、管理者に泣きついてテープの日次バックアップから戻してもらったが、今回はサーバーのイメージはVMwareから移行した際の昨年末のイメージしかない。
ブログのエントリーなど半年分全部ロストか？と思いながら、死んだはずのVMにアクセスしてみたらディスクイメージを消されたにもかかわらずいまだに動き続きている。「しめた！」と思い、まずはそのディスクイメージが入っていたファイルシステムにこれ以上書き込みが起こらないように、Sambaサーバーなどを停止。そして半年前のイメージの別のDomain-UのVMを作り起動し、aptitudeでソフトを自動更新したあと、rsyncでなぜか動いているサーバーとWebのコンテンツや設定ファイルなどを同期させた。で、動いているのを確認してルーターの設定を新しいVMに振り替えた。←いまここ
不思議なことに一晩たったあとも、死んだはずのVMはまだ普通に動いている。Domain-0のカーネルからのloopbackデバイス経由のアクセスはファイルが消えても検知されない仕組みになっているのだろうか？
もちろんシャットダウンしたら二度と起動しないことは確実である。まさにDead Man WalkingならぬDead OS Runningである。このOS動かせ続けてもいいのだが、ファイルシステム的には解放されている領域を読み書きしてるからなるべく早くとめたほうがいい。なので、しばらくして新VMへの同期を確認したらシャットダウンする予定である。これはOSの安楽死なのだろうか？
ええ、買いますよ。買いますとも！！
以前書いたように、DebianのXen環境でこのサーバーを運用しているわけだが、aptitude dist-upgradeでは更新されないようなので、カーネルのアップデートは手動で行う必要があるようだ。
方法は簡単でまずはXenのカーネルを探してみると
$ apt-cache search xen-linux-system
xen-linux-system-2.6.18-4-xen-686 – XEN system with Linux 2.6.18 image on i686
xen-linux-system-2.6.18-4-xen-vserver-686 – XEN system with Linux 2.6.18 image on i686
xen-linux-system-2.6.18-5-xen-686 – XEN system with Linux 2.6.18 image on i686
xen-linux-system-2.6.18-5-xen-vserver-686 – XEN system with Linux 2.6.18 image on i686
xen-linux-system-2.6.18-6-xen-686 – XEN system with Linux 2.6.18 image on i686
xen-linux-system-2.6.18-6-xen-vserver-686 – XEN system with Linux 2.6.18 image on i686
とリストされるので最新版のxen-linux-system-2.6.18-5-xen-686をDomain-0とすべてのDomain-Uインストール。
（追記）下のコマンド間違っていたので修正しました。
$ sudo aptitude install xen-linux-system-2.6.18-6-xen-686
そして/etc/xen/サーバー名.cfgを編集して新しいカーネルに変更
kernel = ‘/boot/vmlinuz-2.6.18-6-xen-686′
ramdisk = ‘/boot/initrd.img-2.6.18-6-xen-686′
これでDomain-0を再起動（当然Domain-Uも再起動）すると、まったく問題なくバージョンアップしていた。
もう先週になるのだが、大学時代にお世話になった先輩とmixiを通じて10年ぶりに連絡をとりあって飲み、10年という時間を忘れて楽しく飲んだ。その節はどうもです。いやはやインターネットで世間は狭くなったもんだとしみじみと感じました。mixiの日記やブログなどは、年に一度「お元気ですか？また飲みましょう」と一行だけ書いた年賀状などよりよっぽど近況報告になるかと思います。
さてFacebookが日本語でもサービスを始めたのでさっそく始めてみたら、予想通りのEarly Adapterな知り合いを発見。友達登録をしてもらいつつTwitterでそのことをつぶやいたら、「日本語でサービス始まったらやはりみんなやってきたな」とのこと。
まだ少ししか使っていないのだが、出身大学や登録した友人などの情報から「この人もあなたは知り合いではないのですか？」などとリコメンドしてくる。A,B,Cの3人がいて、AとB、BとCが知り合いだったらそりゃAとCも知り合いだろうというロジックだろう。Amazonのリコメンドに似ている。
Facebookが日本でどこまでmixiに迫れるのかはちょっと見ものです。
以前、書いたようにRailsアプリの実行環境を作るのはいささか面倒だ。PHPアプリのようにサーバーにアップするだけでは動かず、ちょっと面倒である。
大徳日記 » Railsのアプリの実行環境について調べてみました
が、最近Passenger(mod_rails)なるものが出てきて話題になっているので試してみた。インストールに参考にしたのは次のページ。
Rails 2.0 » ホスティングサービスでもRailsが利用できるようになるかも、な「Passenger」
LoadModuleの設定などを書いておけばあとは簡単だ。仮想ホストのドキュメント・ルートがrailsアプリのpublicディレクトリーになっていればそれでＯＫ。またサブディレクトリの場合も、
<virtualhost *:80>
ServerName www.phusion.nl
DocumentRoot /websites/phusion
RailsBaseURI /rails # This line has been added.
</virtualhost>
としておけばＯＫである。上の例では/railsがrailsアプリのpublicディレクトリーへのシンボリックリンクになっている。詳しくはマニュアルにある。
さてここで疑問に思ったのが、「じゃあ、仮想ホスト毎に１つのRailsアプリしかホスティングできないのか？」ということ。RailsBaseURIを2つ以上指定してもちゃんと動くのか実験してみた。hogeとpiyoという２つのRailsアプリを2つ作ってそれぞれx,yのサブディレクトリにリンク。apacheの設定は次の通り
RailsBaseURI /x/rails
RailsBaseURI /y/rails
さっそくブラウザーでアクセスしてみるとちゃんとどちらも動いていた。すかさず直前のエントリーのコメントでさいとさんに教えてもらった方法でruby1.8のプロセスを見てみる。
UID PID PPID C STIME TTY TIME CMD
root 11021 11020 0 16:51 ? 00:00:00 Passenger spawn server
root 20271 11021 3 22:23 ? 00:00:00 Passenger FrameworkSpawner: 2.0.2
daitoku 20272 20271 0 22:23 ? 00:00:00 Passenger ApplicationSpawner: /home/daitoku/work/hoge
daitoku 20274 1 0 22:23 ? 00:00:00 Rails: /home/daitoku/work/hoge
daitoku 20281 20271 0 22:23 ? 00:00:00 Passenger ApplicationSpawner: /home/daitoku/work/piyo
daitoku 20283 1 0 22:23 ? 00:00:00 Rails: /home/daitoku/work/piyo
rootで動いている上の２つのプロセス(11021と20271)はトップレベルで各アプリ毎に振り分けるためのサーバーなのだろう。で、1レイヤー下に各アプリ毎に振り分けるサーバーがいてそれぞれhogeアプリが20272、piyoアプリが20281ぽい。で、実際にリクエストを処理するのが20274と20283なのではないだろうか？
ためしにabでhogeに対して5並列の負荷をかけてみると、案の定Rails:で始まるプロセスが増えている。1つ多く6プロセスなのは余分に１つ立ち上げているのだろう。
UID PID PPID C STIME TTY TIME CMD
root 11021 11020 0 16:51 ? 00:00:00 Passenger spawn server
root 20271 11021 0 22:23 ? 00:00:00 Passenger FrameworkSpawner: 2.0.2
daitoku 20412 20271 1 22:29 ? 00:00:00 Passenger ApplicationSpawner: /home/daitoku/work/hoge
daitoku 20414 1 12 22:29 ? 00:00:00 Rails: /home/daitoku/work/hoge
daitoku 20418 1 5 22:29 ? 00:00:00 Rails: /home/daitoku/work/hoge
daitoku 20421 1 7 22:29 ? 00:00:00 Rails: /home/daitoku/work/hoge
daitoku 20423 1 1 22:29 ? 00:00:00 Rails: /home/daitoku/work/hoge
daitoku 20425 1 3 22:29 ? 00:00:00 Rails: /home/daitoku/work/hoge
daitoku 20434 1 21 22:29 ? 00:00:00 Rails: /home/daitoku/work/hoge
さらにこの状態で5並列でpiyoにも負荷をかけてみたら、別途piyoも6プロセス起動した。長くなるのでプロセス一覧は割愛するが、hogeのrubyプロセスはhogeの処理だけ、piyoのrubyプロセスはpiyoの処理だけ行うということが判明。うまくして１つのRailsプロセスがhogeもpiyoも処理できるようにするとすごいかも。
いやいやmod_rails便利です。
ひさびさに目から鱗（うろこ）が落ちました。たまたま見つけた次のサイト。
よくサーバーが起動しているかどうか確認するときにpsコマンドで見るじゃないですか。たとえばapacheのプロセスが起動しているかを見るときは
$ ps alx | grep apache
5 33 11347 11020 15 0 158848 2056 341702 S ? 0:00 /usr/sbin/apache2 -k start
5 33 11352 11020 16 0 183436 2132 341162 S ? 0:00 /usr/sbin/apache2 -k start
0 1000 12296 17847 18 0 4956 792 – R+ pts/4 0:00 grep apache
などとするのですが、こうすると運が悪いとgrepのプロセスもリストに入ってきます。で、上記のサイトで知ったTipsは”grep apache”ではなく”grep [a]pache”とすること。実際にはシェルが展開するのを防ぐため「”」でクォートする必要があります。
一瞬、「そんなことしてもapacheも[a]pacheも正規表現的には同じなのでどっちみちgrepプロセスは引っかかってくるよ。」と思いましたが、やってみると確かにgrepプロセスが引っ掛からなくなっている。で、しばらくして「あっ」と気付きました。
そうです。”grep [a]pache”とやるとpsコマンドの結果にも”grep [a]pache”と表示されるので”grep apache”にも”grep [a]pache”にもマッチしません。
ちなみにいつもは”ps alx | grep apache | grep -v grep”などとやってましたがタイプが面倒なので脳内で消していました。横着者の私としてはこれで「”」がなければ完璧なTIPSなのですが…。
WordPress MEが開発を中止したので、本家のWordPress 2.5日本語版に移行しました。参考にしたのは次のサイトです。アップグレードは特に難しいことはなかったのですが、プラグインが使えないものがあるそうでこれらはまたひとつづつ検証していく必要があります。
» WordPress ME 2.2.3からWordPress 日本語版 2.5に移行: たにもりのもり
管理画面はかなり変わりました。見た目はクールです。使い勝手はこれからおいおいですな。
（追記）今まで使用していたプラグインは最新版を落としてきたらすべてちゃんと動きました。