お恥ずかしいハナシだが、うちの仕事場では、いまだにDOSアプリを動かしている。
それは現在、PC-9821Nr13のWin98上DOSモードで動いているが、Nr13がコケてしまうと仕事ができなくなってしまう。
で、La10をバックアップ機として待機させておこうというわけだ。

しかし、データの転送はどうする??
フロッピに収まりきらないデータをISH等で分割してなどという芸当も可能だが、んな悠長なことやってるヒマが無い場合は??
そこに登場するのがFreeBSDである。700MBのHDDをDOS=200MB、FreeBSD=500MBに分割。
メモリ8MBで FreeBSDがインストールできるか怪しかったが、ものは試しとやってみた。

結果、無事に FreeBSD(98)4.8R のインストールに成功。(ただし、5.1Rはインストール途中でコケた)
FreeBSD側からは mount -t msdos すればDOS領域にアクセスできるため、FreeBSDでネットワークを使い、ftpでファイルをGET、DOS領域に保存。(世にも珍しいDOS/FreeBSDデュアルブート)
いやぁー、メモリ8MBでTCP/IPネットワークがマトモに使えるとはなぁ。
とはいうものの、DOS領域では、8+3 の filenameしか使えないので注意が必要だ。

なお、ネットワークカードは、Melco の LPC-2T を使っている。
4.8Rのときは、起動途中のネットワークカード認識の際にフリーズすることがたびたびあったが、4.9Rにしてからは非常に安定に動作している。

bsd-jdk14-patches-6.tar.gz
http://www.eyesbeyond.com/freebsddom/java/jdk14.html

j2sdk-1_4_2_03-linux-i586.bin j2sdk-1_4_2-src-scsl.zip j2sdk-1_4_2-bin-scsl.zip
http://www.sun.com/software/java2/download.html

これらの4つのファイルを取ってきて、/usr/ports/distfiles/ に放り込む。
なお、Sunでは、なぜかレジストしなければならない。

次に、Buildのために、次のコマンドを実行しておく。これを忘れるといつまでたってもmakeが終わらない。
kldload linprocfs
mount -t linprocfs linprocfs /compat/linux/proc

で、ようやく、cd /usr/ports/java/jdk14 して、 make install するのだが、これが長い。えんえんと3時間近くmakeが続くのであった。こんなん、gcc以来か?

終わったら、
cd /usr/X11R6/lib/mozilla/plugins して、
ln -s /usr/local/jdk1.4.2/jre/plugin/i386/ns610/libjavaplugin_oji.so .
すれば、MozillaでJavaプラグインが使えるようになりましたとさ。

もう少し具体的に書くと、例えば、「えんこ」と入力して「エンコ」に変換・確定すると [あ連] が消えてしまって、その後はShift-Spaceを押しても半角スペースが入力されるだけなのである。
(つまり、カタカナに変換すると、kinput2が機能停止してしまう)
cannaのLogには、request failed とかのエラーが残っている。

ただし、kinput2をいったんkillして再度実行(あるいは、Mozillaを再起動)させると、再び入力できるようになる。
konqueror等他のアプリではこの症状はおきない。

KDEを使わず twm上でMozillaを使った場合は不具合が発生しないため、原因はKDEにあるのではないかと勘ぐったのだが、じつは kinput2とgtk2-MozillaとKDEの相性というか、kinput2側の問題のようなのである。

Netを検索しても回避策がなかなか見つからず、kinput2の不具合であると想定して検索したところ、ようやく回避策にたどり着くことができた。

.Xdefaults に次の3行を追加する。

Kinput2*SeparateConversion.input: false
Kinput2*selectionShell.input: false
Kinput2*auxShell.input: false

*SeparateConversion.input: false
*selectionShell.input: false
*auxShell.input: false

squid-2.5STABLE* を動かしているマシンが 1か月に数回落ちてしまうという症状にしばらく悩んでいたのだが、STABLE6 が出たということでパッチをチェックしたら、
「Segfaults and other strange crashes when using heap policies」なんてのが出てた。
回避策は、「Use the default lru polic」だそうで、そーいえば、heapにしてから落ちるようになった気が・・

当初、nmbclustersの不足を疑ったので、sysctl.confで kern.ipc.nmbclusters: 65535 となるよう設定したのだが、それでも落ちてる。
なお、1週間で100万リクエスト以上を処理しているものの、squid利用のピーク時間帯には1回も落ちていないし、利用者がごくわずかと考えられる日時にも落ちていた。(それで、nmbclusters は、あとになって もうちょっと少な目に)
squidはキャッシュを書き込んで、暇なときに旧いキャッシュをまとめて削除するみたいなので、キャッシュの削除時にコケていたのかもしれない。

ということで、まさにそれだ!! こいつが犯人だ!! 状態 で喜々として再インストール&パッチ当て作業(というか、今回は ports) したのだが・・・・はたして真犯人なのか??

後日譚

前述のパッチを当てても、依然として落ちるという状態が続いていた。/var/log/messages や /usr/local/squid/var/logs/cache.log を見ても、なんら記録されておらず、原因がまったく判らない。なお、Proxyとしてのsquidの動作には何ら異常は認められない。
ちなみに、CPU=PIII 600MHz、メモリ=768MB、OS=FreeBSD-4.9RELEASE である。

それで、キャッシュファイルが変になっているのかもしれないと squidを止め、キャッシュファイル(約4GB)の削除を実行したら消してる途中でOSが落ち、リブート。いつもと同じ落ち方のようだった。再起動後、もう一回削除を試みたが、今度はハングアップ。その際のメッセージは、以下のとおり。

panic: backgroundwritedone : lost buffer

また、こんなのが出たこともあった。
panic: softdep_fsync_mountdev : not dirty

というわけで、この時点でsquidが犯人である可能性はほとんどなくなった。OSであるFreeBSDか、ハードウエアの問題ということになる。
また、ファイル削除時にコケるということで、HDDが怪しいのではということになり、これを新品と交換もしてみた。しかし、症状は改善されなかった。

FreeBSD-users-jp (メイリングリスト)で本件について質問してみたところ、OS側ではなくハード、それもマザーボードかメモリが原因である可能性の指摘があり、memtest86 でメモリテストを実行してみたところ、数万のエラーがバラバラ出た。そこで、怪しい(旧い)メモリを1枚(256MB)外して動かしたら・・・今のところ squid-2.5STABLE7 は落ちてはいない。

それにしても、なぜメモリを取り替える・・・その前にメモリテストの試行ということに気づかなかったのか・・・まったくもって悔やまれる。(ユーザが多く使用頻度も高いサーバなので、あまり止めたくなかった・・ということはあるのだが・・・)

さらなる後日譚

メモリテストでエラーが出たメモリを、他のマシンに挿して再度メモリテストをしてみたら、ノーエラーだった。また、別の正常なはずのメモリを squidマシンに挿してみたら、エラーになってしまった・・・・ということは、ぱんぱかぱーーーん!! マザーボードのどこか(またはCPU?)がおかしいのだ。

ということで、現在は squidのキャッシュサイズを大幅に切りつめ、またメモリをできるだけ使わない設定にして様子をみている状態である。

けっきょく

1か月間に10回も落ちるような状態ではガマンも限界である。ちょうど一次業務から引退したサーバ機が出たので、こいつに 4.11-RELEASE-p9をインストールし、squidを移行することにした。移行後は何ごともなく動いてくれているようだ。
ちなみに、不具合の出たサーバのマザーボードは、TYAN のTiger133である。このマザーは怪しすぎる・・と思うぞ。

08/17/2004 XFree86 4.4.0 の keymap

なにげなく portupgrade してしまって(^^;)、XFree86が 4.4.0にバージョンUPしてしまった。
それだけならいいのだが、なぜか keymap が変更になったらしく、ひらがなの「ろ」が入力できなくなってしまったのである。この症状は、以前にもあった。
片っ端からキーを押してみると、SHIFT+@ で「ろ」になる。まあ、このままでも使えることは判ったが、underscore が出ないのも困るし、再度keymapをイジることにする。

xev を使って keycode を確認すると、「ろ」のキーコードは、211番になってしまっているらしいので、mykeymap.kbd の中身の211のところを keycode 211 = grave underscore kana_RO と修正した。

05/15/2005 5.4-RELEASE

zcr.jpのサーバを FreeBSD 5.4-RELEASEにVersion-Up。4.10からのUpdateなので、もちろんクリーン・インストールである。メイジャー・バージョンアップは、3系列から4.0に上げたのが確か2000年だったので5年ぶり。各データファイル、設定ファイルは tar で固めてWindowsマシンに吸い上げておいた。

ところで、733MHzのPentium IIIで5.4にしなけりゃならない理由というものはない。kernelは重くなっているだろうし、これが仕事で使っている業務用サーバであれば、5.4にはせず4系列のままにしておくだろう。しかし、自宅サーバ、しょせん道楽である。(^^;)

5.4-RELEASEのisoファイルをNetからダウンロードし、CD-Rに焼いたのだが、なんと、現用サーバのCD-ROMドライヴではCD-R(Windows機で作成)が読めないことが発覚。しかたないので、焼いたCDからインストール用フロッピを作成。

\floppies>fdimage boot.flp a:
\floppies>fdimage kern1.flp a:
\floppies>fdimage kern2.flp a:

フロッピからインストーラを起動し、ネットワークからFTPでシステムファイル等をダウンロードしてなんとかインストールを完了した。

ところが、今度はSSHでWindowsのクライアントから接続できないという問題が・・・。どうも、4から5になったときにSSH2がデフォルトになったらしい。いつも使っているTTSSHはSSH1にしか対応していない。どうせ外からのSSH接続はDenyしているので、/etc/ssh/sshd_config を書き換えて Protocol 1 にする。Keyも転送していないので、一時的に PasswordAuthentication yes にしてsshdを再起動。

なお、もともと sshdを動かしていなかったホストの場合、ssh_host_key のロードに失敗する。当該ファイルが無いのだから当然である。新規作成するには、ssh-keygen -t rsa1 (SSH1の場合) して、/etc/ssh/ssh_host_key を指定する。

自宅サーバは5.4にバージョンUPさせたけれど、仕事場のサーバは230MHz〜930MHzだし、メモリあんまりないし、 止められる時間も限られているし・・・というわけで、当然5.*-RELEASE系列へのバージョンUPは行わないことにした。4系列のままあと1年程度はもたせる予定である。(しかし、1年で済むのか!??・・・よく考えたら、予算がつくのか怪しいような・・・^^;)