CTRL-CでOpenSimが落ちないようにする

OpenSimを端末ウィンドウでうごかしてる場合、CTRL-Cを押すと中断されて落ちてしまいます。これはWindowsでもUNIXでも同じです。UNIXの場合は、端末でCTRL-Cを押すとSIGINTというシグナルが発生し、その端末上で動いているプログラムを中断させます(デフォルトの動作の場合)。

私は、WindowsマシンでViewerを動かしながら、OpenSimが動いているサーバーにTeraTermで接続してOpenSimのコンソールを操作しています。CTRL-CはWindowsでは、Copy&PasteのCopyのショートカットキーになってますので、Windowsのノリで、sshの端末画面の上で間違えてCTRL-Cを押してしまうことがよくあります。また、UNIXのShellのコマンドラインでは入力途中のコマンドをCTRL-Cを押して中断・破棄するということもよくやります。

そういう手クセがついていると、OpenSimのコンソールでついついCTRL-Cを押して、誤ってOpenSimを落としてしまうことがあります。こないだも、OSGridの私のリージョンに人が来ていたにもかかわらず、CTRL-Cを押してしまったようです(手クセなんで、あんまり自覚がない。ごめんなさいwww)。

これを防ぐために、次のような「opensim_start.sh」というスクリプトでOpenSimを起動するようにすると、CTRL-Cを押しても大丈夫になります。

#!/bin/sh
stty intr undef
mono --debug OpenSim.exe
stty intr ^C

キモは、「stty intr undef」 というコマンドで、intr (SIGINT)を発生させる文字コードを未定義にしてからOpenSimを起動してます。これで、OpenSim起動中はCTRL-Cを押してもなにも起こりません。そして終了前にCTRL-Cに戻しています。sttyの詳細についてはオンラインマニュアルを見てください。

まあ、これで不用意にOpenSimを落としてしまうことが少なくなると思います(^_^;)。

OSGridで動画を撮ってみた

BlogにYouTube動画を張ったことがなかったので、試しにやってみました。撮影場所は、OSGridのMARTYS ART GALALERY II というリージョンです。アバターは、「hop://login.osgrid.org/Tryloria%202/192/48/22」でもらったHexeというVampireアバです。

録画は、BB FlashBack Express 2 というソフトでしました。 今見たら、BB FlashBack Express 3がでてました。

動画の撮りかたや編集は、まだ良くわかってないので、適当にやってます。まあ、いちどちゃんとマニュアルや、解説本を読まないと....(^_^;)。

解決: ビュアーが原因だったかも...(変な現象が発生)

「変な現象が発生」という記事で、リージョンにある木々が隣のリージョンにずれて表示されるという Cool VL Viewer v1.26.5.16 のバグですが、v1.26.5.18 で直ったようです。

Cool VL Viewer v1.26.5.18で隣のリージョンを見たところ。正常に見えている。

ChageLogにも説明がありました。

Cool VL Viewer v1.26.5.18 (experimental branch with v3.4 renderer):

Same changes as in v1.26.4.38, plus:

• Fixed tree rendering (phantom trees sometimes appearing on the horizon when hovering over a parcel with trees) and tree shadows issues (bad shadows).

作者は、このBlogを見たのかしらwww。

monoのバージョンを2.10.8にあげてみた

monoのバージョンを 2.10.6 --> 2.10.8に上げてみました。

リリースノート
http://www.mono-project.com/Release_Notes_Mono_2.10.8

FreeBSDのportsのmono (lang/mono)は、2.10.6 の次は、2.11.1 にいきなりバージョンが上がってるようですが、ここは、portsのMakefileに小細工して、2.10.8をインストールしてみました。正式にPortsになっているバージョンではないけど、細かいバグ修正が修正されているようなんで、ためしに使ってみます。

ビュアーが原因だったかも...(変な現象が発生)

ついさっき公開した「変な現象が発生」という記事ですが、どうやらビュアーのバグのようです(>_<)。

「変な現象が発生」の記事を書いた時に使っていたのは、Cool VL Viewer v1.26.5.16 でした。このv1.26.5は、「Cool VL Viewer v1.26.5 (new, EXPERIMENTAL branch with the new v3.4 renderer)」という、テスト版です。

Firestorm 4.2.2 (29837)で、INしてみたところ、問題なく表示されました。また、 CoolVLViewer-1.26.4.36 (安定版)、Imprudence 1.3.2、Imprudence 1.4.0 beta 2でも、問題ありませんでした。

Cool VL Viewerの1.2.5.x (テスト版)を使ってたのは、アバターを表示するときに、アバタのスキンなどのテクスチャーが変になりにくいからです。

というわけで、ビュアー側の問題のようでした。お騒がせして申し訳ありませんでした。

変な現象が発生

!!! 注意 !!!
この記事の変な現象は使っていたビュアー(Cool VL Viewer v1.26.5.16)が原因だったようです。 詳しくはこちら「ビュアーが原因だったかも...(変な現象が発生)」をごらんください。


OSGridの私のリージョン(New Galapagos 2)で、変な現象が発生しました。
このリージョンは、OpenSim Creationsにあった、OAR(OpenSimulator Archive)ファイルのThe Path V0.7をリージョンに読み込んだものです。

本来リージョンの上にあるハズの木々が、 隣のリージョンにずれて表示されています。

不思議なことに、そのリージョンに降りると、アバターの周辺には隣にあった(2)の位置から、本来あるべき(1)の場所に木が戻ります。

また、隣のリージョン((2)の位置)に移動して自分のリージョン((1)の位置)の方をみると、一瞬(2)の位置に木々が見えるんですが、次の瞬間にアバターから2つ遠い先のリージョンに木々が移動してしまいます。

うーん....。

この現象は、opensim-36bfd36 (OSgrid OpenSimulator 0.7.5.dev.36bfd36) にあげた後、しばらくしてから気づきました。
OpenSimのバージョンをあげたことが原因なんだろうかと思って、一つ前の opensim-4e9509d に戻しましたが、同じ現象になりました。もっとも、OpenSimのバージョンを上げても同じMySQLのデーターベースを継続して使ってるので、データベースのリージョンに関するデータがおかしかったら戻しても変わらないのかもしれません。

木のオブジェクトがロックされてなくて、それを全選択してしまってて、操作ミスで移動させてしまったんだろうか? リージョンのデータベースが変になった???

いったん、リージョンを削除し、もう一度OARを読み込ませればいいのかなぁ.... (>_<)。

ODE 0.12をGIMPACTで再コンパイル

先月、「ODE 0.12にアップデイト」というBlogエントリを書いたのですが、OpenSim ODEで検索してたら、次のような記事を見つけました。これは、opensim-devのメーリングリスト(ML)に投稿されたもののアーカイブのようです。

Prospective ODE physics changes (将来のODE物理に関する変更)
http://opensim-dev.2196679.n2.nabble.com/Prospective-ODE-physics-changes-td7144808.html

このMLのスレッドは、18個ほど投稿がされています(Threadedのリンクをクリックするとスレッド一覧が見れます)。

議論の中身はあんまり理解できない(^_^;)のですが、collider(コライダー? 衝突検出器?)に従来のOPCODEではなく、GIMPACTを使ったほうがクラッシュしにくいとか、[ODEPhysicsSettings]の中の contacts_per_collision というパラメータを80からもっと小さい値にしてもいいんじゃないか、とかが議論されています。まあ、詳しくは、上記MLのスレッドをご覧ください。

ODE 0.12の再構築

前回のODE 0.12のコンパイルでは、「http://opensimulator.org/wiki/PhysicsEngines」の内容に従って、configureのオプションを決めたのですが、今回は「--with-trimesh=gimpact」のオプションをつけることにします。

まずは、前回の 「ODE 0.12にアップデイト」の手順に従い、ソースコードを取得し、FreeBSD用パッチをあてます。その後、「sh autogen.sh」でconfiguareスクリプトを作成して、次の引数をつけてconfigureを実行します。

# ./configure --disable-asserts --enable-shared --disable-demos --with-drawstuff=none --with-trimesh=gimpact CFLAGS="-O2 -msse -mar
ch=i686" CXXFLAGS="-O2 -msse -march=i686"

ちょっと見ずらいので、複数行で表記すると次のようになります(UNIXのShellは行末に「\」がある場合、次の行と連結して1つの行として扱います)。

# ./configure --disable-asserts --enable-shared --disable-demos \
              --with-drawstuff=none --with-trimesh=gimpact \
              CFLAGS="-O2 -msse -march=i686" \
              CXXFLAGS="-O2 -msse -march=i686"

後は、make & install します。

# make
...
... 
# make install
...
...

この新しいODEのライブラリだと、クラッシュしにくくなったような気がします。

contacts_per_collision パラメーターの調整

OpenSim.iniの [ODEPhysicsSettings] セクションに contacts_per_collisionのパラメータを追加します(ODEに関するパラメータの大部分は、OpenSimDefaults.ini にあります。OpenSim.iniはそれに追加・上書きしています)。

[ODEPhysicsSettings]
    contacts_per_collision = 10

このcontacts_per_collisionの値を小さくすると、物理オブジェクトを使ったときのCPUの負荷が劇的に減ります。10 の値が妥当なのかどうかは判りませんし、なんか乗物等で不都合がでるかもしれません。でも、物理な0.5m角のCUBEを400個くらい積み上げて崩してみても、前よりはアバターが動けるように感じますし、崩れ方・転がり方も、以前よりすこし自然な感じがします。
それと、いまのところクラッシュしていません。まあ、私の主目的は、クラッシュしないことですんで、これでとりあえず良しとします。

物理オブジェクトの掃除のTips

物理オブジェクト を積み上げて崩すという遊びをしていると、コンソールに「 [PHYSICS]: Physical Object went out of bounds.」という警告メッセージがどんどんでたり、あっちこっちに散らばった物理オブジェクトを探し回って消さなくてはいけなくなることがあります。
こんな場合、OpenSimの次のようなコンソールコマンドを使うと便利です。

delete object outside - Delete all scene objects outside region boundaries
delete object name [--regex]  - Delete a scene object by name.
show object name [--regex]  - Show details of scene objects with the given name.

範囲外にでたオブジェクトは、「delete object outside」コマンドで削除します。
物理オブジェクトに、あらかじめ特徴的な名前をつけておいて、「delete object name --regex オブジェクト名の正規表現」とすれば、探し回わって消さなくてもすみます。間違って他のオブジェクトを消してしまわないように、あらかじめ、「show object name --regex ...」で消すオブジェクトを確認しといたほうがいいかもしれません。


a

メモリリークの原因

OpenSim Version 0.7.5 (Dev)Build 4e9509d にアップデイトしてみましたが、相変わらずメモリ使用量は時間とともに増加するようです。
Kimiko Dover さんの「OSgridのメモリー消費増加の原因」って記事を前にみてたので、試しに OpenSim.iniの[Startup]セクションの次の3つの設定をコメントアウトにしてみました。

[Startup]
    ...
    ;WorldMapModule = "WorldMap"
    ;MapImageModule = "Warp3DImageModule"
    ;GenerateMaptiles = true

コメントアウトし、しばらく動かしてみてますが、メモリ使用量の増加はおこらないようです。psコマンドを定期的に動かしてメモリ使用量を記録するスクリプトをcronで動かしてみてますが、増えたり減ったりしてます(減ることもある)。
vsizeが仮想記憶メモリサイズ(KB)で、rssが常駐メモリサイズ(KB)です。

タイムスタンプ       vsize  rss    コマンドライン
2012-10-09 23:00:00  316780 224232 mono OpenSim.exe
2012-10-09 23:30:00  316780 224232 mono OpenSim.exe
2012-10-10 00:00:00  316780 224232 mono OpenSim.exe
2012-10-10 00:30:00  316780 224232 mono OpenSim.exe
2012-10-10 01:00:00  316780 224256 mono OpenSim.exe
2012-10-10 01:30:00  316848 224304 mono OpenSim.exe
2012-10-10 02:00:00  316848 224332 mono OpenSim.exe
2012-10-10 02:30:00  316848 224340 mono OpenSim.exe
2012-10-10 03:00:00  316848 226112 mono OpenSim.exe
2012-10-10 03:30:01  316848 214680 mono OpenSim.exe
2012-10-10 04:00:00  316848 213312 mono OpenSim.exe
2012-10-10 04:30:00  316848 210284 mono OpenSim.exe
2012-10-10 05:00:01  316848 210284 mono OpenSim.exe
2012-10-10 05:30:00  316848 210296 mono OpenSim.exe
2012-10-10 06:00:00  316848 208484 mono OpenSim.exe
2012-10-10 06:30:00  316848 208484 mono OpenSim.exe
2012-10-10 07:00:00  316848 209968 mono OpenSim.exe
2012-10-10 07:30:00  316848 209968 mono OpenSim.exe
2012-10-10 08:00:00  316848 209968 mono OpenSim.exe
2012-10-10 08:30:00  316848 209968 mono OpenSim.exe
2012-10-10 09:00:00  316848 209972 mono OpenSim.exe
2012-10-10 09:30:00  316848 209972 mono OpenSim.exe
2012-10-10 10:00:00  316848 209972 mono OpenSim.exe
2012-10-10 10:30:00  316848 209972 mono OpenSim.exe
2012-10-10 11:00:00  316848 212752 mono OpenSim.exe
2012-10-10 11:30:00  316848 212756 mono OpenSim.exe
2012-10-10 12:00:00  316848 212756 mono OpenSim.exe
2012-10-10 12:30:00  316848 212756 mono OpenSim.exe
2012-10-10 13:00:00  316848 212760 mono OpenSim.exe
2012-10-10 13:30:00  316848 212760 mono OpenSim.exe
2012-10-10 14:00:00  316848 212760 mono OpenSim.exe
2012-10-10 14:30:00  316848 212760 mono OpenSim.exe
2012-10-10 15:00:00  316848 213096 mono OpenSim.exe
2012-10-10 15:30:00  316848 213096 mono OpenSim.exe
2012-10-10 16:00:00  316848 213096 mono OpenSim.exe

Warp3DImageModuleについては、「http://opensimulator.org/wiki/Warp3DImageModule 」に記述があります。

Warp3DImageModuleを使わないと、マップに表示される画像がしょぼくなりますが、メモリリークしなくなります。なので、使わない方向でしばらく動かそうと思います。

ちなみにOSG48のメンバーの方によると、WindowsでOpenSimを動かしている場合は、このようなメモリリークは起こらないそうです。

Warp3DImageModule、もしくはmono特有の問題なのかもしれません。libgdiplusとかX11とかのライブラリとかが関係しているのかも...。

OpenSim Version 0.7.5 (Dev)Build 4e9509d にアップデイト

OSGridのOpenSimの新しいバージョンがリリースされていましたので、アップデイト掛けてみました。

OpenSim Version 0.7.5 (Dev)Build 4e9509d[r/20546]

 正常に起動されているようです。まあしばらく様子をみてみます。

メモリリークしてる?

topコマンドで、OpenSimを動かしているmonoのメモリ使用量モニタしてるんですが、時間の経過とともに徐々に大きくなってきます。ちなみに、OpenSimのバージョンは、OSgrid OpenSimulator 0.7.5.dev.224efe7です。

起動直後は次のような感じ(COMMANDがmonoのところのSIZEとRESに注目)。

last pid: 20123;  load averages:  0.47,  0.27,  0.15        
81 processes:  1 running, 80 sleeping
CPU:  4.7% user,  0.0% nice,  2.2% system,  0.1% interrupt, 93.1% idle
Mem: 457M Active, 1969M Inact, 218M Wired, 2676K Cache, 112M Buf, 349M Free
Swap: 2048M Total, 3360K Used, 2045M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
20105 opensim    51  46    0   336M   255M ucond   3   1:10 15.23% mono
 1673 mysql      17  44    0   192M 45720K sbwait  1  17:33  0.00% mysqld
...
... 以下省略
...

だいたい51時間後は、次のような感じ。メモリ使用量がほぼ倍になってます。

last pid: 20086;  load averages:  0.20,  0.15,  0.10
83 processes:  1 running, 82 sleeping
CPU:  1.3% user,  0.0% nice,  3.0% system,  0.0% interrupt, 95.7% idle
Mem: 734M Active, 1947M Inact, 212M Wired, 2740K Cache, 112M Buf, 99M Free
Swap: 2048M Total, 3368K Used, 2045M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
78208 opensim    54  44    0   619M   515M ucond   3 563:00  8.30% mono
 1673 mysql      16  50    0   192M 45708K sigwai  2  17:32  0.00% mysqld
...
... 以下省略
...

「opensim メモリリーク」で検索してみたら 、Kimiko Dover さんの「Opensimで、メモリーリークが起きているのかな？ 」って記事がヒットしました。メモリ使用量増加の割合もだいたい同じぐらいです。

このペースでメモリ使用量が増えたら、ほかにもサービス動いてるし、ちょっとこのマシンでは苦しいなぁ...。問題が根本的に解決されるまで、定期的に再起動かけるようにするかな。ハードウェア共用のVPSとかをレンタルされている方は苦しいかもしれませんね。

OSG48に参加しました

OSG48とは、OSGridに接続している日本人オーナーのリージョン郡です。私も、このリージョン郡へお誘いをうけて、参加させていただきました。当初1つのリージョンだけのつもりだったんですが、「何事も経験だからまとめて引越ししたら?」との事で、それじゃあ、ということで4つまとめて移動してきました。

周りにたくさんのリージョンがあります。お隣さん、よろしく!

 お隣の高い山のリージョンから自分のリージョンを眺めるの図。

いまのところ、安定してるとは思うけど、昨日物理オブジェクト400個だしたら、core dumpしてOpenSimが死んでしまった。ODEには、まだなんか潜在的な問題があるのかなぁ? それともOpenSimの側の使い方の問題?

OpenSimが死んだとき、自動的にリカバリーする仕組み、そろそろつくらないと...。

ODE 0.12にアップデイト

いままで、ODE(Open Dynamics Engine)は、FreeBSDのPorts(devel/ode)のものを使ってました。このバージョンは 0.11.1です。いま、ODEプロジェクトのホームページを確認したら、0.12がでていました。0.11.1が出たのが 2009-10-17で、0.12が2012-05-28 ですので、いろいろとバグが修正されていることが期待できます。まだ、Portsは0.11.1のまんまなんで、ここは手動でソースコードからライブラリをインストールすることにします。

automakeをインストール

ODEのコンパイルには、automakeが必要ですので、Portsからインストールします。

# cd /usr/ports/devel/automake && make install clean

依存関係のあるPortsもあわせてインストールされますが、まあ、気にしない。
automakeはODEをコンパイルする為だけに必要で、実行時には必要ありません。

ソースコード取得とパッチあて

ODEのサイトの download のリンクをたどると、sourceforgeのサイトにいきます。そこから、「ode-0.12.tar.bz2」をダウンロードし、展開します。ダメなら、ブラウザ等でいったんダウンロードしてから、FreeBSDに転送します。

# fetch http://sourceforge.net/projects/opende/files/ODE/0.12/ode-0.12.tar.bz2
# tar xvzf ode-0.12.tar.bz2
...
... ファイルが展開される
...

展開したソースコードのMakefile.amに次のパッチを当てます。こちらからダウンロードするか、コピペして、「ode-0.12_freebsd.patch」というファイル名で保存してください。

--- Makefile.am.orig    2012-02-12 07:03:27.000000000 +0900
+++ Makefile.am 2012-09-19 21:24:49.000000000 +0900
@@ -40,5 +40,5 @@
         CHANGELOG.txt INSTALL.txt README.txt LICENSE.TXT \
         bindings

-pkgconfigdir = $(libdir)/pkgconfig
+pkgconfigdir = $(libdir)data/pkgconfig
 pkgconfig_DATA = ode.pc

このパッチを当てないと、monoがlibode.soを見つけられなくてエラーになります。odeのソースコードがFreeBSDの devel/pkgconf の仕様に適合してない為みたいです。

# cd ode-0.12
# patch -p1 < /some/where/ode-0.12_freebsd.patch

configure & make

パッチがあたったら、sh autogen.shを実行して、configureスクリプトを作成します。

# sh autogen.sh

次にconfigureスクリプトに、次の引数をつけて実行します。

# ./configure --disable-asserts --enable-shared --disable-demos --with-drawstuff=none CFLAGS="-O2 -msse -march=i686" CXXFLAGS="-O2 -msse -march=i686"

CFLAGSとCXXFLAGSに「-O2 -msse -march=i686」をつけているのは、IntelCPUのSSE命令などをつかって、ちょっとでも最適化し、性能を上げようとしてます。サーバーのCPUのアーキテクチャにあわせて、適切なものに変えるといいかもしれません(どのくらいパフォーマンスが稼げるのかは不明)。

では、ソースコードをmakeし、エラーがなければインストールします。

# make
...
... 
# make install
...
...

インストールが完了したら、OpenSim.exeを再起動します。エラーなく起動されればOK。

動作確認

さて、うまくうごいているか動作を確認してみます。
まずは、CUBE を500個だし、物理属性をつけます。

 

 だんだん崩れていきます。

 ぺっちゃんこになりました。

さすがに、500個も物理オブジェクトを出すと、身動きがとれません。ちなみにOpenSimを動かしているコンピュータは、Intel ATOM D525、メモリ4GBです。

 CUBEの中を歩き回ります。まともに動けませんけど、OpenSimは落ちないみたいです。

この時の、topコマンドによるプログラムの状態は、次の通りです。

last pid: 86961;  load averages:  1.13,  0.77,  0.48                                           up 5+10:20:55  01:07:55
93 processes:  2 running, 88 sleeping, 3 stopped
CPU: 25.5% user,  0.0% nice,  2.3% system,  0.0% interrupt, 72.1% idle
Mem: 503M Active, 2020M Inact, 224M Wired, 61M Cache, 112M Buf, 188M Free
Swap: 2048M Total, 2528K Used, 2045M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
86679 opensim    53  44    0   413M   322M ucond   3  10:17 104.98% mono
 1673 mysql      16  50    0   192M 45656K sigwai  2   7:24  0.00% mysqld
 2242 opensim     1  44    0 11900K  8732K select  0   0:54  0.00% screen
68091 opensim     1  44    0  3688K  1688K CPU2    1   0:04  0.00% top
 1685 root        1  44    0  3384K  1120K nanslp  1   0:04  0.00% cron
 1460 root        1  44    0  3352K  1096K select  1   0:03  0.00% syslogd
.....
.....
.....

重いのは重いけど、sshで接続しているセッションは普通に操作できます。
また、私のリージョンサーバーは、現在4つのリージョンがあるのですが、CUBEをぶちまけた隣のリージョンにテレポートしたら、そこでは普通にうごけました。

また、500個も物理オブジェクトをぶちまけると、次のような警告がOpenSimのコンソールに沢山でます。

01:04:41 - [PHYSICS]: Physical Object went out of bounds.
01:04:41 - [PHYSICS]: Physical Object went out of bounds.
...
... 途中省略 ...
...
01:05:01 - [PHYSICS]: Physical Object went out of bounds.
01:05:03 - [PHYSICS]: Physical Object went out of bounds.
01:05:03 - [PHYSICS]: Physical Object went out of bounds.
Region (root) #

これらのオブジェクトは、地面の下にもぐっていたり、リージョン境界でぐるぐるまわってたり、隣のリージョンまでいってしまってたりします。ビュアーのArea Search等で、オブジェクトを探して、一つ一つ削除していかないといけなくなります(>_<)。作業を簡単にするため、あらかじめ物理オブジェクトには、検索しやすいような名前をつけておくことをお勧めします。

まとめ

まだ、もっと様子をみないといけないけど、ODEがいきなり落ちてしまうということはなくなったかもしれません。

プロセスのメモリ上限を増加させた(ODEがエラーで落ちた)

ODEがエラーで落ちるという件ですが、プロセスが使えるメモリ上限が少ないためにでていたのかもしれません。OpenSimのサイトの次のページを見てみると、Linuxの場合プロセスが使うスタックの最大サイズを262144KBにしろとあります。

http://opensimulator.org/wiki/PhysicsEngines

In Linux you should consider using included shell script, opensim-ode.sh or type ulimit -s 262144 before running mono OpenSim.exe if you plan on having a large number of physics objects (each avatar is a physics object, as well as those which have the physics flag set on the simulator). The ulimit -s 262144 in Linux protects you against stack collisions and corrupted memory when there are a large amount of physical objects roaming around.
(個々のアバターは、物理オブジェクトと同じ扱い)

 
 FreeBSDの場合、カーネルパラメーターでプロセスが確保できる、データサイズ、スタックサイズ等の上限が設定されています(これ以上は指定しても増えない)。

# sysctl kern.maxdsiz kern.maxssiz
kern.maxdsiz: 536870912
kern.maxssiz: 67108864

このサイズはすべてのプロセスの最大値なので、すべてのプロセスはこの上限を超えてメモリを確保することはできません。プロセス毎に小さく設定することはできます。また、子プロセスは親プロセスのリソース制限を(ファイルディスクリプタや、環境変数などと同じように)継承します。

現在のプロセス(というか対話しているshell)のリソース制限値は次のようにして調べられます(limit, ulimit という csh, sh の内蔵コマンドでも表示できる)。

# /usr/bin/limits
Resource limits (current):
  cputime              infinity secs
  filesize             infinity kB
  datasize               524288 kB
  stacksize               65536 kB
  coredumpsize         infinity kB
  memoryuse            infinity kB
  memorylocked         infinity kB
  maxprocesses             5547
  openfiles               11095
  sbsize               infinity bytes
  vmemoryuse           infinity kB
  pseudo-terminals     infinity
  swapuse              infinity kB

これをみると、データーサイズ 524288KB、スタックサイズ 65536KBで、OpenSimのサイトの注意書きにあるスタックサイズ262144 KBにくらべて小さすぎることがわかります。

大きくするには、/boot/loader.conf に次のように設定します。

#
# for OpenSim ODE(Open Dynamic Engine).
# ODE require  262144KB or more Stack Size.
# 
kern.maxdsiz="1024M"
kern.maxssiz="512M"

(#はコメントなのでいらないけど、後でなぜそうしたのかわかるように書いておくほうが吉。)
まあ、これだけ大きければOKかも。でも大きいということは、メモリリークするプログラムとかがあった場合、検出するまでに時間がかかったり、検出した時点では、システムのメモリ使い尽くしてしまっててOSごと落ちるということもないとは言えないので、ある意味慎重に設定したほうがいいとは思います。

こうしておいて、OpenSimを立ち上げると、140個ぐらいの物理属性つけたCUBE をぶちまけても落ちなくなりました。ただし、そのリージョンではすべての動作が遅くなり、すごく重くなります。まあ、すべてのフレームにおいて、物理オブジェクトの位置と回転を計算し、その変化した位置情報をビュアーにUDPパケットで送らないといけないので、CPUも使うし通信するデータ量もかなり増えてしまうからなんだろうとは思いますが....。OpenSim.iniのパラメータをいじったら、すこし緩和できたりするのかしら?

 ただ、落ちなくなるといっても限界があり、260個ぐらいだして、ぶちまけたCUBEのなかをアバターで歩き回るとやはり前のようなエラーがでました。

ODE INTERNAL ERROR: disabled body tagged
Stacktrace:

  at (wrapper managed-to-native) Ode.NET.d.WorldQuickStep (intptr,single) <0xffffffff>
  at OpenSim.Region.Physics.OdePlugin.OdeScene.Simulate (single) <0x01383>
  at OpenSim.Region.Framework.Scenes.SceneGraph.UpdatePhysics (double) <0x00029>
  at OpenSim.Region.Framework.Scenes.Scene.Update (int) <0x004af>
  at OpenSim.Region.Framework.Scenes.Scene.Heartbeat () <0x000bf>
  at System.Threading.Thread.StartUnsafe () <0x00059>
  at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) <0xffffffff>
Abort (core dumped)

この、「ODE INTERNAL ERROR: disabled body tagged」ってのが出る条件が良くわからない。中身を理解するのは、私のレベルでは無理だけど、エラーがでて、システムがとまってしまうのは困るなぁ...。

ODEがエラーで落ちた

物理オブジェクトいじってたら、次のようなエラーでOpenSimが落ちた(>_<)。

Region (Neo Galapagos) #
ODE INTERNAL ERROR: disabled body tagged
Stacktrace:

  at (wrapper managed-to-native) Ode.NET.d.WorldQuickStep (intptr,single) <0xffffffff>
  at OpenSim.Region.Physics.OdePlugin.OdeScene.Simulate (single) <0x01383>
  at OpenSim.Region.Framework.Scenes.SceneGraph.UpdatePhysics (double) <0x00029>
  at OpenSim.Region.Framework.Scenes.Scene.Update (int) <0x004af>
  at OpenSim.Region.Framework.Scenes.Scene.Heartbeat () <0x000bf>
  at System.Threading.Thread.StartUnsafe () <0x00059>
  at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) <0xffffffff>
Abort (core dumped)

私のコンパイルしたODEには、まだ問題があるのかなぁ...。

ちなみに、OpenSimのバージョンは、opensim-dd0556a。

OSGridのリージョンを増やしました

OSGridのOpenSimサーバーがそれなりにうごいているみたいなんでリージョンを増やしてみました。リージョン増やすのは、bin/Regions/Regions.ini に記述を増やし、リージョン毎に別のInternalPortを割り当てればOKです。具体的な方法はこちらが参考になります。

ちなみに、この4つのリージョンは、メガリージョンにしていません。いちどメガリージョンにしてみたんですが、土地区画を分割したときに、あとで追加したほうのリージョン内の区画で音楽URLは設定できるけど、その区画に入ったときにビュアーの音楽が切り替わらないという現象がありました。そういうわけで今のところメガリージョンにしてません。設定項目とかに抜けがあるのかもしれませんので、確認して後日再挑戦してみることにします(^_^;)。

この状態でmonoのメモリの使用量は SIZE=470MB, RES=371MB、CPU使用率は3-5%、メモリは4GB積んでるんで、まだ余裕あります。CPUは、物理オブジェクトを動かすと急に使用率が増えます。物理オブジェクトが無い状態だと、2-3%以下なんですが、物理なBOXオブジェクトを7個ほど出すと、15～20%に跳ね上がります。CPUがATOM D525なんで、CPU負荷がかかるようなのはつらいのかもしれません。まあ、でもこの程度なら、まだまだ大丈夫かな?

このうちの一つのリージョンをOSG48という日本人オーナーのSIM郡に接続してもらう予定です(OSGrid 48だと思う。なんで48なのかは不明。48リージョンつなげるぞーーってことなのかな? ちなみにオレオレ詐欺48ではないwww)。

OSGridのすごいSIM

OSGridは、基本的に自分で設定したOpenSimをテストするグリッドという意識があったので、あまりうろうろはしてませんでした。でも、自分のOpenSimが接続できたので、しばらくぶりにうろうろしてみたところ、けっこう完成度の高いリージョンがちらほらあったりします。

次のスクリーンショットは、Laniというリージョンの宇宙ステーションで撮ったものです。宇宙ステーションの中は全部つながってて、かなり広い空間になっています。SecondLifeでこういうSIMを所有しようとすると、(金銭的に)かなり大変ですけど、OpenSimだと十分可能です。

ただ、まだまだアルファレベルのソフトウェアなんで、普通の人が簡単にというわけにはいきません。また、SLとちがって、人があんまりいないし、イベントもなさそうなんで、なんらかの目的意識がないとまったく面白くないかもしれません。まあ、SecondLifeの完成度になるには、まだまだ時間がかかるとは思います(SecondLifeとは方向性がちがうけどね)。

まあでも、試しにアカウントとってINしてみるのも面白いかもしれませんね。

OSGrid接続成功!

今朝、OSGridが復旧していたので、再度接続を試してみたら成功しました!

早速音楽流してみました(^_^;)。

とりあえずやってみたのレベルなので、DBもSqllite3だったり、サーバー再起動したときに自動起動しないとか、いろいろ調整するところはあるけど、まあ、とりあえずはメデタシメデタシです。

ダウングレード完了だが....

Mono 2.10.6とNant 0.90 へのダウングレードは完了して、次のバージョンのOpenSimをビルドしてみました。

• opensim-0.7.3.1-source.tar.gz (OpenSimのサイトから取得したもの)
• opensim-dd0556a.tar.gz (OSGridの7.4 DEV版の最新)

これらを、スタンドアローンモードで動かしたところ、一応正常に動作しているようでした。

OSGridに接続するにあたって、OpenSimをFreeBSDのJail環境内で動かしています。Jail環境の中で動かせば、万一外部から進入されても、ホスト側の環境までは進入しにくいのではないでしょうか。

sysutils/ezjailを使って、Jail環境を作り、その中にホスト環境で作成済みのバイナリーpackageをインストールしOpenSimをビルドしました。しかし、うごかしてみたら、これが起動途中でExceptionが発生し、止まってしまいます。原因がよく分らなかったので、とりあえずJail環境の中にPortsツリーをマウントして、ビルドしなおしました。
結局 libgdiplusのライブラリがうまく作成できてなかったような感じです(ソースに若干のパッチが必要)。あと、devel/pkg-config がdevel/pkgconf に置き換わってたりしているので、それらの影響がでてたのかもしれません。
いろいろもがいてて、やっとのことで安定してOpenSimをビルドできるようになりました。この辺りは、落ち着いたらまとめたいと思います。

OSGridの7.4 DEV版がビルドできたので、試しにOSGridに接続してみようと思い、OSGridのサイトを見ながら設定し、OpenSimを起動したところ、途中で固まってしまいました。OSGridのWebサイト にブラウザでアクセスしようとしたら、OSGridのサイトが落ちているようで、アクセスできません。ビューアでINしようとしてもできませんので、サイト全体が落ちているようでした。

というわけで、OSGridへのお試し接続は次回とします。

OpenSim環境のアップデイト (mono, nantのダウングレード)

古いバージョンのmonoで試したら、うまく動作しているみたいなので、monoを2.10.6へ、nantを0.90にダウングレードしてみます。

portdowngrade

PortsツリーをCVSとかで取得・展開している場合は、「cvs update -r リビジョン」で素直に古いバージョンを取り出せばいいんですが、インストール時にPortsツリーも展開してたり、CVSupで最新版をとってきているような場合、portdowngradeというツールを使うと便利です(実は、最近知った ^_^;)。

portdowngradeの使い方を調べるのも面倒なら、CVSwebから直接該当するバージョンのPortsファイルをダウンロードして、手動で置き換えたほうが早いかもしれません。でも、ここはせっかくだからportdowngradeを使ってみます。

portdowngradeは以前は、「sysutils/portdowngrade」にあったのですが、現在は「ports-mgmt/portdowngrade」に移動しています。 portupgradeをインストールしているのであれば、次のコマンドでインストールできます。

# portinstall ports-mgmt/portdowngrade

ではダウングレードしてみましょう。環境変数CVSROOTにAnonymousCVSサーバーのpserverの情報をセットします。現在のFreeBSDハンドブックによると、今のところ、台湾とフランスのサーバーしか動いてないみたいです。昔は日本にもサーバーがあったのですけど、Subversionに移行したから、減ってるのかなぁ。
cvs pserverは、まず使う前にloginします。初回は~/.cvspassファイルが無いので警告がでますが、気にしないでいいです。2回目以降からでなくなります。

# setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs
# cvs login
Logging in to :pserver:anoncvs@anoncvs.tw.freebsd.org:2401/home/ncvs
CVS password: (anoncvsといれる。なんでもいいみたいだけど)
cvs login: warning: failed to open /root/.cvspass for reading: No such file or directory

次に、portdowngradeでlang/monoを2.10.6にダウングレードします。

# portdowngrade lang/mono

portdowngrade 0.6 by Heiner Eichmann
Please note, that nothing is changed in the ports tree
unless it is explicitly permitted in step 6!

Seeking port lang/mono ...

Found several matches:
1: lang/mono
2: lang/mono-basic

Please choose one: 1 (<--- lang/monoに複数マッチするから、適切なものを選ぶ)

Downgrading port: lang/mono

Step 1: Checking out port from CVS repository
CVS root directory (from CVSROOT environment variable): :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs

Step 2: Reading the port history from the CVS repository

Step 3: Analyzing the port history from the CVS repository

Step 4: Load port version numbers and present results
Keys: <space> : next page                      d : details
            p : previous page
      <enter> : leave presentation and downdgrade if wanted
======================================================================================================================
number         date         portversion  comment
    1  2012/06/29 18:24:08  2.11.1       - Remove SITE_PERL from *_DEPENDS
    2  2012/05/13 07:48:35  2.11.1       Fix build when devel/libinotify is installed
    3  2012/05/02 18:16:19  2.11.1       Update to 2.11.1.
    4  2011/10/08 23:13:36  2.10.6       Update to 2.10.6.
    5  2011/09/21 17:52:24  2.10.5       Update to 2.10.5.
    6  2011/06/12 19:06:22  2.10.2       Hello Mono 2.10!
    7  2011/05/13 16:12:53  2.6.7_1      Force commit to fix wrong info in last commit log
   ... 
   ... ずらずらとでてくるので、適当なところで <enter>キーを押すと、
   ... そこで中断し、どの番号(number)のPortsを取り出すか聞いてくる。
   ...

Total lines: 113. Command:
Enter version number to change port to (0: exit): 4 (<--- 4番が2.10.6のバーション)


Step 5: Checking out choosen date of the port from the CVS repository

Step 6: Modifying the port
Port: lang/mono
at : 2011/10/08 23:13:36
Type 'yes' to bring the port to the state of the date above
or 'no' to exit without changing anything. Note, that this only changes
the port, not the installed software! yes or no:yes (<--- yesで修正をかける)

The port has been set to the selected version. Install it if you wish.
If you have portupgrade installed, you should run

portsdb -Uu

now, to see the changes in the ports database. In any case

portupgrade -f mono

will install the changed port. Note: if you run cvsup, the port
is changed back to the choosen label!

devel/nantも0.90にダウングレードします。

# portdowngrade devel/nant

portdowngrade 0.6 by Heiner Eichmann
Please note, that nothing is changed in the ports tree
unless it is explicitly permitted in step 6!

Seeking port devel/nant ... found: devel/nant

Step 1: Checking out port from CVS repository
CVS root directory (from CVSROOT environment variable): :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs

Step 2: Reading the port history from the CVS repository

Step 3: Analyzing the port history from the CVS repository

Step 4: Load port version numbers and present results
Keys:  : next page                      d : details
            p : previous page
       : leave presentation and downdgrade if wanted
======================================================================================================================
number         date         portversion  comment
    1  2012/07/27 06:50:38  0.91         SVN rev 301591 on 2012-07-27 06:50:38Z by erwin
    2  2012/01/21 18:54:09  0.91         - Extend BROKEN tag to all amd64
    3  2012/01/15 21:39:34  0.91         - Mark BROKEN on amd64/9:
    4  2011/10/27 17:30:50  0.91         - Update to 0.91
    5  2011/04/12 15:19:26  0.90         - Remove obsolete MD5 checksum
    6  2010/09/22 17:10:21  0.90         - Update MAINTAINER to my FreeBSD.org address
    7  2010/06/30 11:37:00  0.90         - Update to 0.90
    8  2009/11/18 22:39:50  ${PORTNAME}-0.85-src_1  - Mark MAKE_JOBS_UNSAFE
    9  2009/08/22 00:18:17  ${PORTNAME}-0.85-src_1  - Switch SourceForge ports to the new File Release System: categor
   ... 
   ... ずらずらとでてくるので、適当なところで <enter>キーを押すと、
   ... そこで中断し、どの番号(number)のPortsを取り出すか聞いてくる。
   ...

Total lines: 23. Command:
Enter version number to change port to (0: exit): 5 (<--- 5番が 0.90のバーション)


Step 5: Checking out choosen date of the port from the CVS repository

Step 6: Modifying the port
Port: devel/nant
at : 2011/04/12 15:19:26
Type 'yes' to bring the port to the state of the date above
or 'no' to exit without changing anything. Note, that this only changes
the port, not the installed software! yes or no:yes (<--- yesで修正をかける)

The port has been set to the selected version. Install it if you wish.
If you have portupgrade installed, you should run

portsdb -Uu

now, to see the changes in the ports database. In any case

portupgrade -f nant

will install the changed port. Note: if you run cvsup, the port
is changed back to the choosen label!

次に、portdowngradeで指示されていたようにportupgradeでインデックス等を作り直し(時間かかります)、まずmonoを作成しなおします。

# portsdb -Uu
...
# portupgrade -f lang/mono
...

次にnantを次のように作成しなおそうとしましたが、なんかエラーになりました。

 
# portupgrade -f devel/nant
...
...
Unhandled Exception: System.ArgumentException: failed to convert parameters
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in :0
  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in :0
  at NAnt.Console.ConsoleStub+HelperArguments.CallConsoleRunner () [0x00000] in :0
  at System.AppDomain.DoCallBack (System.CrossAppDomainDelegate callBackDelegate) [0x00000] in :0
  at (wrapper remoting-invoke-with-check) System.AppDomain:DoCallBack (System.CrossAppDomainDelegate)
  at NAnt.Console.ConsoleStub.Main (System.String[] args) [0x00000] in :0
[ERROR] FATAL UNHANDLED EXCEPTION: System.ArgumentException: failed to convert parameters
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in :0
  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in :0
  at NAnt.Console.ConsoleStub+HelperArguments.CallConsoleRunner () [0x00000] in :0
  at System.AppDomain.DoCallBack (System.CrossAppDomainDelegate callBackDelegate) [0x00000] in :0
  at (wrapper remoting-invoke-with-check) System.AppDomain:DoCallBack (System.CrossAppDomainDelegate)
  at NAnt.Console.ConsoleStub.Main (System.String[] args) [0x00000] in :0
gmake: *** [install] Error 1
*** Error code 2

Stop in /usr/ports/devel/nant.
*** Error code 1
...

いろいろやってみたところ、結局 portupgradeを使わずに、 手動でmake installすればうまくインスートルできました。

 
# cd /usr/ports/devel/nant
# make clean
# make install

エラーが起こってしまったのは、mono 2.11.1の残骸でも残っていたのだろうか...。 原因究明は、またの機会にします(^_^;)。

まあ、とりあえず、これでダウングレード完了です。

OpenSim環境のアップデイト (xbuildをつかってみる)

SL内で、 Rikachann Aabyeさんにnantの代わりにxbuildを使ってみてはと言われて試してみました。OpenSimのソースに同梱のBUILDING.txtにも、「May also use xbuild (included in mono distributions)」と書いてありました。

ちなみに、OpenSimのソースは、opensim-0.7.3.1-source.tar.gzをOpenSimのサイトからとってきました。 また、Portsアップデイト後のmonoのバージョンは次の通りです。

% mono --version
Mono JIT compiler version 2.11.1 (tarball Mon Aug 13 11:48:31 JST 2012)
Copyright (C) 2002-2012 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           normal
        SIGSEGV:       normal
        Notification:  kqueue
        Architecture:  x86
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            Included Boehm (with typed GC and Parallel Mark)

まずは、runprebuild.shを実行してからxbuildを実行してみます。

% ./runprebuild.sh
Prebuild v2.0.5
Copyright (c) 2004-2010
...
... 省略 ...
...
% xbuild
XBuild Engine Version 2.11.1.0
Mono, Version 2.11.1.0
Copyright (C) Marek Sieradzki 2005-2008, Novell 2008-2011.

Build started 08/19/2012 16:09:03.
__________________________________________________
Project "/usr/home/opensim/opensim/opensim-0.7.3.1-source/OpenSim.sln" (default target(s)):
        Target ValidateSolutionConfiguration:
                Building solution configuration "Debug|Any CPU".
...
... 省略 ...
...
        /usr/local/lib/mono/3.5/Microsoft.Common.targets:  warning : Found a conflict between : 'mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' and 'mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyTok
en=b77a5c561934e089'. Using 'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' reference.
        /usr/local/lib/mono/3.5/Microsoft.Common.targets:  warning : Found a conflict between : 'System, Version=2.0.0.
0, Culture=neutral, PublicKeyToken=b77a5c561934e089' and 'System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b
77a5c561934e089'. Using 'System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' reference.

         204 Warning(s)
         0 Error(s)

Time Elapsed 00:03:05.2317040

xbuildは一応成功しているように見えます(本当は出力を詳細に調べる必要があるけど...)。 binディレクトリにおりて、OpenSim.ini等の設定ファイルを設定し、OpenSim.exeを起動してみます。

% mono OpenSim.exe
16:44:07 - [OPENSIM MAIN]: configured log4net using default OpenSim.exe.config
16:44:07 - [OPENSIM MAIN]: System Locale is
16:44:07 - [OPENSIM MAIN]: Runtime gave us 200 worker threads and 8 IOCP threads
16:44:07 - [OPENSIM MAIN]: Bumping up to 500 worker threads and 1000 IOCP threads
16:44:07 - Performing compatibility checks...
16:44:07 - Environment is compatible.
16:44:07 - [CONFIG]: Reading configuration settings
16:44:07 - [CONFIG]: Reading configuration file /usr/home/opensim/opensim/opensim-0.7.3.1-source/bin/OpenSimDefaults.ini
16:44:07 - [CONFIG]: Reading configuration file /usr/home/opensim/opensim/opensim-0.7.3.1-source/bin/OpenSim.ini
16:44:07 - [LOGGING]: Logging started to file /usr/home/opensim/opensim/opensim-0.7.3.1-source/bin/OpenSim.log
16:44:07 - [OPENSIM MAIN]: Using async_call_method SmartThreadPool
16:44:07 - [STARTUP]: Beginning startup processing
16:44:07 - [STARTUP]: OpenSimulator version: OpenSim 0.7.3.1 Release
16:44:07 - [STARTUP]: Operating system version: Unix 8.2.10.0, .NET platform Unix, 32-bit
16:44:07 - [APPLICATION]:
APPLICATION EXCEPTION DETECTED: System.UnhandledExceptionEventArgs

Exception: System.TypeLoadException: Could not load type 'OpenSim.Framework.Console.CommandConsole' from assembly 'OpenSim.Framework.Console, Version=0.6.5.29081, Culture=neutral, PublicKeyToken=null'.
  at OpenSim.Framework.Servers.BaseOpenSimServer.Startup () [0x00000] in :0
  at OpenSim.Application.Main (System.String[] args) [0x00000] in :0

Application is terminating: True
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: Could not load type 'OpenSim.Framework.Console.CommandConsole' from assembly 'OpenSim.Framework.Console, Version=0.6.5.29081, Culture=neutral, PublicKeyToken=null'.
  at OpenSim.Framework.Servers.BaseOpenSimServer.Startup () [0x00000] in :0
  at OpenSim.Application.Main (System.String[] args) [0x00000] in :0

なんだか良くわからない例外(Exception)が発生しています。うーん、OpenSim.Framework.Console.CommandConsole は OpenSim/Framework/Console/CommandConsole.cs のソースの中で定義されているクラスっぽいけど....なんでだろ。

古いバージョンのmonoで試してみる

mono のバージョンが 2.10.6 のままのマシン(nantも0.90でちゃんとうごいてたもの)があったので、これでopensim-0.7.3.1を展開し、コンパイルしてみたところ、すんなりコンパイル&実行できてしまいました。FreeBSDの mono 2.11.xx は、OpenSimを動かすにはまだ不具合が多いってことなのかしら....。

というわけで、今日はここまでにします(^_^;)。

OpenSim環境のアップデイト (nantが...)

VirtualBox の中の OpenSim環境のアップデイトを始めたんですが、いろいろと変わってて、すんなりと動きません。
nantが0.91になってMakefileに

BROKEN=         fails to build

とマークされてます(BROKENの意味はこちら)。そのまんまではなんかすんなりコンパイルできないようです。
VirtualBoxに割り当ててた仮想ディスクの容量(4GB)もいろいろビルドしてると、足りなくなくなったようで仮想ディスクを10GBで作成し dump & restoreで複製つくります。

ちゃんと動くようになるまで、まだまだかかりそう。変化しつつあるシステムを追っかけるのは大変だな。

OpenSim環境のアップデイト

やはり不定期日記の名の通り、一年くらい放置してしまいました(^_^;)。一応データベースをMySQLにしたりするのはやってみてましたが、OpenSimやmonoバージョン等も上がってきているので、ここらで一度いろいろアップデイトかけようと、作業を始めました。

 インストールしているPortsのアップデイトには、portupgrade というツールを使っています。Ports間の依存関係とかにあまり頭を使わなくてすむので、楽ができます。portsツリーのアップデイト方法やportupgradeの使い方などは検索してみてください。

というわけで、今、VirtualBox の中の FreeBSD&OpenSim 環境をアップデイト中。かなり時間かかりそう...。