ここでは、わたしが遭遇した問題と、その解決方法を書いていきます。
どうか、宝の山となりますように。夢の島となりませんように。
まず、VNC 自体をインストールしなければなりません。VNC っていったい何？ という方は、google などで検索してください。とてもたくさんのページが見つかるはずです。以降では、VNC を知っていること、UNIX の基礎知識があるものとして話を進めます。
さて、Linux にインストールする VNC は 3.3.3r2 以降にしましょう。これは、コンパイルなしに inetd で動作させるために必要です。それ以前のバージョンの場合は、パッチと再コンパイルが必要になります。バイナリを VNC のページからダウンロードしてきたら、適当な場所に展開しましょう。するといくつかのバイナリと README などが展開されますので、README を読みつつ、必要なバイナリを /usr/local/bin へコピーしてください。
Windows にインストールする VNC はどんなものでも構いません。最新のものを突っ込んでおきましょう。こちらは展開すると InstallShield のインストーラができます。あとはそれを実行するだけです。簡単ですね。
次は Linux 側で /etc/inetd.conf と /etc/services を編集します。これに関しては ゼロ円でできる X サーバ という記事に詳細が書かれていますので、そちらを参照してください。編集が終わったら、inetd に HUP を送るのを忘れないようにしてくださいね。もしくは、再起動を行います。/etc/rc.d/init.d にあるスクリプトを実行してもいいでしょう。
さて、これで VNC 経由での接続ができるようになりました。しかし、このままでは文字化けや色化けが起こる可能性があります。少なくとも、わたしの環境ではその両方が発生しました。
色化けはウィンドウマネージャに Sawfish を使っている場合、発生するようです。わたしが使用したときはビットマップの大半が色化けを起こしていました。もしかするとこれはウィンドウマネージャのプログラムにバグがあるのかもしれません。そこで WindowMaker を使うようにすると、まったく何の問題もなく動作してくれました。8 ビットカラーで使用すれば Sawfish でも問題ないのですが、それはちょっと嫌ですよね？ 結局、色化けする事になってしまうし。
文字化けの方は、ちょっとばかり複雑です。通常、VineLinux 2.1.5 では xfs という X 用のフォントサーバが使われています。このサーバを通してデータを持ってくるようにすると、文字化けが解消されます。
/etc/inetd.conf に書かれた Xvnc の行を次のようにします。
vnc stream tcp nowait nobody /usr/local/bin/Xvnc Xvnc -inetd -query ホスト -once -geometry 800x600 -depth 8 -fp unix/:-1 -deferglyphs 16 -co /usr/X11R6/lib/X11/rgb
|
-co に関しては、無くても何とかなるかもしれません。-deferglyphs は、なぜ必要なのかわかりません(笑)。インターネットで調べていたら見つかっただけですので。
ともかく、上のようにしてフォントパスを設定すれば動くはずです。
もしそれで動かなければ、-fp tcp/localhost:7100 などとすると動くかもしれません。
こちらのページ にある PDF には、かなり詳しく、いろいろなことが書かれています。設定に詰まったら、こちらも参照してみてください。ちなみに、VineLinux 2.1 では inetd 経由でログインすると「5」キーが「BS」になってしまうそうな。これの原因は不明です。VineLinux 2.0 では起こらなかったということなので、アップデートの際に紛れ込んだバグなのでしょうか。
強引にキーマップを変更するという手段によって対処することができます。ただし、「5」が入力できない状態なのに「5」を打たなければならないという矛盾した状況になっていますので、予めエイリアスを張っておくなどしておく必要があります。
xmodmap -e 'keycode 22 = 5 percent'
|
「ELF interpreter /usr/libexec/ld-elf.so.1 not found」
このメッセージがすべての幕開けでした。
研究に使うためのプログラム (以下では研究用プログラムと書きますね) をコンパイルし、実行すると直後に上のようなエラーが発生して、まったくプログラムが動作しないのです。わたしは「/usr/libexec/ld-elf.so.1 というファイルが見つからないのかな」と考え、上のエラーメッセージで WWW から同じような症例、および、ld-elf.so.1 を探し始めました。
が、よくよく調べてみると、/usr/libexec の下にはちゃんと ld-elf.so.1 というファイルが置かれています。
「……存在するファイルが見つからない？」
ldconfig も実行してみました。……ダメ。
他の FreeBSD から ld-elf.so.1 をコピーしてきました。……ダメ。むしろ悪化(笑)。
ほかの FreeBSD マシンにソースを移して、そっちでコンパイルしてみました。……これまたダメ。
ところが、SunOS では同じプログラムがちゃんと動作するのです。いったいこれはなぜ？
研究室の他の人に手伝ってもらいながら原因究明を進めていると、「このエラーメッセージはもしかして、『ELF interpreter /usr/libexec/ld-elf.so.1』が『not found』と言っているという意味なのではないか？」という仮説が。……だとすると？ どうなるのでしょう(笑)。まあ、少なくとも、ライブラリが無い、というわけではないみたいです。ELF リンカはちゃんと認識されている、と。
もしやすると gcc が原因か？ というわけで、Hello World の単純なプログラムをコンパイルしてみると……ちゃんと動きます。
もう残るはソースしか無い！ ということで、ソースを眺めてみます。最初の「ライブラリが足りない (インストールされていない) のかな？」という疑問から、かなり遠ざかってしまいましたよね……。ソースを眺めていると、上記のエラーの原因になりそうな部分より、ソースの汚さの方が目についてしまったりして、なかなか思うように作業が進みません(笑)。
うーん、ということで、これまでは FreeBSD 4.x で作業していたのですが、これを FreeBSD 2.2 で動いているマシンに持って行ってみます。こっちは ELF など無い環境なので、きっと違ったことになるだろう、と。コンパイル、さあ実行！ 「Cannot allocate memory.」メモリが足りないと怒られてしまいました。今度はライブラリ絡みのエラーは出なかったぞ、何か、進展した感じ。じゃあ、このメッセージは研究用プログラムのどこで出力されているんだ？ と grep をかけてみますが……何も見つからない。どこにも該当するエラーメッセージを出力する部分がないのです。ということは、システムがメッセージを出しているのですよね。
今度は Linux に持っていってみます。すると、コアダンプ(笑)。
ソースを見ても、とくにおかしいような部分は無い……というか、SunOS では動いているのだからロジック的におかしいというような事はあり得ない。じゃあ、やはりライブラリが足りないのか？ でも 2.2 系で出てきたエラーメッセージの説明がつきません。
ん？ 待てよ？ ……もしかして、メモリが足りないのか？
ソースを書き換え、while ループで止まるようにし、top で使用メモリを調べてみると……500MB もくっている！ メモリ説の気配が一気に濃くなります。
ならばということで、静的に確保している領域を大幅に減らし、コンパイルしてみます。今度は……動く！ 動くぞ！
次は FreeBSD のカーネルを書き換えて、利用できるメモリの領域を増やしてみます。メモリが 1G 近く載せてある PC があるのですけれど、その PC で使われている FreeBSD のカーネルはユーザー一人あたり最大で 500MB ほどしか使用できないようにコンパイルされていたのでした。リミットを書き換え、カーネルコンパイル、そして再起動！
……カーネルパニック！？ というのも当然で、載せられたメモリのギリギリまで確保してしまったのです。これではカーネルを置く場所がなく、カーネルパニックになるのも当然です。今度はちょっと控えめな値にして、再起動。今度はちゃんとうまく行きました。limit で使用できる最大メモリを確認すると、ちゃんと 1GB になっている。
今度こそ！ ということで実行すると……やった！ 動いた！
つまり、今回の事件の背景は次のようなものでした。
まず、バイナリが ELF 形式なのでリンカの ld-elf.so.1 が呼び出されます。が、静的なデータ領域に 500MB 以上も要求されてしまったので、リンカは「そんなのできねー」とエラーを発生させます。ところがどっこい、そのエラーを捕獲するところがうまくできていないらしく、エラーメッセージとして「〜 not found」というものが表示されてしまっていたのです。
つまり、まったくライブラリが原因に関与していないのに、表面に出てくるエラーメッセージにはライブラリの痕跡しか見つけられなかったため、混乱してしまったのです。
なかなか遭遇しないような事態かもしれませんけれども、もしかすると、という事があるかも。
Windows2000 系の話題です。おそらく WindowsXP でも通用する話だと思いますけれど。
たとえば CD-R への書き込みソフトのようなハードウェアを扱うようなプログラム (カーネルモードでの動作がほとんどというプログラム) では、ひとたびハングアップしてしまうとどうにもできなくなってしまい、Windows の終了すらできない (ように見える) 場合があります。タスクマネージャでプロセスを強制終了させようとしても「できません」と却下されてしまいますし、「Windows の終了」を選択してもまったく変化無し、どうにもできないような場合です。
が、実は後ろではシステムがプロセスの終了を待っていまして、一分ほど 待っていればちゃんとプロセスを殺して終了してくれます。また、ログアウト時にも終了していないプロセスを待つことがあり、そこでもかなりの時間がかかってしまう可能性があります。もしかすると、プロセスは終了しておらず、残したままシステムをシャットダウンしているという可能性もありますけれど。
というわけで、「やべっ、終了しないっ！」という場合でも、しばらく待ってみましょう。辛抱強く、辛抱強く。アニメーションが起こっていたり、マウスカーソルを動かせる場合、Windows のシステムはまだ生きています。
ただ、Windows95 などにおいては、ハングアップしたらほぼ絶望的なので、リセットしかないですね。