2007年9月7日金曜日

キーライム

パッケージの絵が変だったので、それだけの理由で、選んでしまいました。

キーライム
 (明治乳業)



20070906



パッケージに書いてある説明によれば

キーライムはライムの一種で、一般的なライムよりも小ぶりでさわやかな酸味と香りが特徴的です。

とのことでした。知りませんでしたよ、キーライム。
ノンカロリーってのも、いいですね。
ノンカロリーでも、やっぱり甘いんですが、個人的には、甘くない飲み物が好きです。





柑橘系で好きなのが「すだち」。ちょっともの足りないときもありますが、1回で使いきれるくらいの、こじんまりしたところが、いいですね。



この夏、某コンビニの、冷たいうどんで、すだちが入ってるのがありましたが、あれ、安いし、昼飯にちょうどよかったです。なにしろ暑くて暑くて。





台風9号接近中。
いつもそうですが、被害が出ない範囲内なら、台風って、もうワクワクドキドキなんて楽しいんでしょう。



子供のころ、台風が来るっていうので、幼稚園や学校が早く終わり、家では、雨戸を閉めているせいで、昼間なのに、もう暗くなっちゃってて、非日常的なあの不思議な雰囲気が、とっても印象的でした。





ハードディスクが壊れたっぽくて、新しいハードディスクを買ってきたのですが、さきほど、ようやく、新しいハードディスクで、Windowsを起動できるところまできました。
FreeBSDで、ddコマンドを使って、パーティションを丸ごとコピーする、という荒技を使ったのですが・・・予想以上に、ディスク、へたれ気味でした。bad sectorもちらほらと。やばかったなぁ~。



なんとなくそうだろうという気はしていましたが、書き込みがおかしいだけ、ってことはなくて、やっぱり、読み出しも、まずいなぁ~な状態になってました。



それにしても、ディスクの故障を予想するに役立つはずの機能、SMARTでは、これまで、何にも出てこなかったんですけど・・・



まだCドライブしかコピーしていないので、残りもさっさとコピーしよう。



2007年9月6日木曜日

月餅風ミニパン

先日、

次は、月餅風パンで、ようするにアンパン、ってのが出てくるのでは(笑)

なんて適当なことを書いたら、本当にありました(笑)。



月餅風ミニパン



20070905



これも同じく、横濱開港150周年、「濱くら」シリーズになってます。





次は、マンゴープリン風のメロンパン?



(2007-09-07) メロンパンはアンニンスウと重なってしまうので、肉まん風の蒸しパンかも。







■ 過去記事







2007年9月5日水曜日

ハードディスクを買ってきた ~ Seagate ST3320620AS 320GB SATA

どうやらハードディスクが壊れかけているらしいことがわかったので、週末に買いに行くつもりだったのですが、やっぱりすぐなんとかすべきだろう、ってことで、今日、買ってきました。



ここ最近は、Western Digitalが続いていたのですが、今回は、気分転換というか、久しぶりに別のメーカーにしてみようかなぁ、というかんじで、Seagateにしてみました。




20070904



Seagate
Barracuda 7200.10
ST3320620AS
SATA 320GB cache 16MB





あわてて買ってきたわりには、まだ封も切っていないけど。



仕事が終わったあと、いつものように自転車でアキバまで買いに行ってきたんですが、大手町あたりで、地面が濡れてて、あれ、雨降ったのかな?と気になったのです。



そして、買い物をすませ、ぶらぶら寄り道をすることなく、さっさと出発。帰り道、夕飯の買出しなどのため、スーパーに立ち寄り、外へ出ると・・・どしゃぶり!?



うそ!と思ったのですが、3分ほど雨宿りしてたら、止みました。ラッキー!とさっさとうちに帰って、しばらくすると、またどしゃぶり・・・



すごい幸運かも。



自転車に乗ってるとき、雨に降られるのって、かなりきついんですよね。とくに荷物をもっているときなど。





2007年9月4日火曜日

急にネットワークが遅くなった・・・予想外の原因

一昨日の話。

なんか今日になって急に、うちにあるパソコンの、ある1台でだけ、ネットワーク経由のファイルのコピーが非常に遅くなってしまって、非常に、困っています。
USB HDDを抜き差しして、なんとか対処しているんですが、なんとも、めんどくさい!

つまり、ネットワークの通信速度がやたらと遅くなってしまって、いろいろ原因をさぐってみていたのですが、原因が、わかりました。



試してみたこと。



スイッチングハブを変えてみたけど、だめ



ネットワークケーブルを変えたけど、だめ



最近Windows Updateしておかしくなったのでは?と疑い、Windows XPの「システムの復元」を実行して、3、4日前のところへ戻したけど、だめ



READだけ遅くなってて、WRITEは正常。つまり、その不調なパソコンへファ
イルをコピーするとき(IN)だけ、遅くなっていて、その不調パソコンから、別のパソコンへコピーするとき(OUT)は、正常。一律遅くなるわけじゃなくて、一瞬速度がでるときもあれば、遅くなったりと、バタバタしてる。



20070903



200709032




TCPのプロトコル的な問題で(ウインドウ・サイズとか)、パフォーマンスが落ちているんじゃないかという気がして、ツールでパラメータをいじくってみたけど、変化なし。



別のネットワークカードをさしてみたけど、似たような挙動を示し、やっぱり、incomingなトラフィックだけが劇的に遅くなる。



遅くなっているとき、画面描画がしばらく止まったり、マウスクリックしても、すぐには反応しなくなったりなど、ユーザーインターフェイス面でも、もたもたするようになっていることに気がついた。



そういうのって、過去の経験では、割り込み処理関係で、なにかおかしくなっているのが原因だったことがあったので、調べてみた・・・よくわかんねぇ! (笑)



という感じで、なんだかハードウェア故障っぽいけど、ソフトウェア的な問題っぽさもあるなぁ、という感じでした。



そのとき、ふとひらめいたことがあって、あることを、試してみました。それは

ネットワークからコピーするファイルの、コピー先を、USB接続のHDDにしてみた

おっ!正常な速度に戻った。 原因判明です!

内蔵ハードディスクへの書き込みが、異常に遅くなっている

てゆーか

内蔵ハードディスクが壊れかけ?

っていうことですか。



READは今のところ大丈夫で、細々とWRITEするのはとくに問題なさそう(実は、いろいろ試してみて、ちょっと怪しいかんじがしてきている)、ただ、どっかんどっかんと、大量にWRITEするときだけ、なんか失敗してリトライしているのか、ものすごく遅くなっているみたいなのです。



ファイルのコピー(WRITE)が始まった瞬間だけは早いのですが(上のタスクマネージャのグラフで、INの最初だけ、ぴょんと立ち上がってる)、これって、きっと、バッファリングが効いていて、バッファが一杯になるまでは速度が出ていて、そのうちHDDへの書き込みでひっかかりはじめると、そういうわけですね。



そういえば、先週、2回ほど、休止状態(RAMの内容をHDDを保存して電源を切る)にしたとき、妙に時間がかかったあげく、最終的にフリーズした、ってことがあったんですが、それも、このHDDへのWRITEが不安定になっているのが原因っぽいです。



土曜日か日曜日に、アキバ行って、新しいHDDを買ってくるので、週末まで、なんとかもってほしい。神様、お願い!





まぁ、とりあえず、重要なファイルは、さっさと別HDDへコピーしておきますか。



2007年9月3日月曜日

(FreeBSD) cvsup-mirrorの設定ミスのために、変なところで悩んでしまった話

1ヶ月くらい前から、FreeBSD-currentなマシンで、cvsupして、make buildkernelすると、必ず、こんなエラーがでて、カーネルがビルドできなくなってました。



# make buildkernel



~略~
===> coff (cleandir)
rm -f export_syms ibcs2_coff.ko ibcs2_coff.kld imgact_coff.o ibcs2_coff.ko.debug ibcs2_coff.ko.symbols vnode_if.h vnode_if_newproto.h vnode_if_typedef.h
rm -f @ machine
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> coretemp (cleandir)
cd: can't cd to /usr/src/sys/modules/coretemp
*** Error code 2



Stop in /usr/src/sys/modules.
*** Error code 1



Stop in /usr/obj/usr/src/sys/GENERIC.
*** Error code 1



Stop in /usr/src.
*** Error code 1



Stop in /usr/src.



/usr/src/sys/modules/coretempというディレクトリが、なぜか存在しないのです。



# ls /usr/src/sys/modules/coretemp
ls: /usr/src/sys/modules/coretemp: No such file or directory



ちなみに、coretempって何だ?って思ったのですが、てっきり、coreダンプのcoreと、テンポラリファイルのtempなどを想像していたのですが、Intel Core 2シリーズのCPUの、温度(temperature)センサー関係のドライバらしいです。



最初のころは、cvsのファイルが更新されてなくてエラーがでてるのかと思ってたのですが、cvsレポジトリを覗いてみたら、ちゃんと存在してるじゃないですか。



http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/sys/modules/coretemp/



cvsupサーバは、cvsup-mirrorを使って、オフィシャルなcvsupサーバから、ローカルマシンへミラーリングして、そのローカルなcvsupサーバを使っています。



supfileは、こんなかんじで、今までちゃんと使えてました。



# cat /etc/cvsup.CURRENT
*default  tag=.
*default  host=ローカルなサーバ
*default  base=/usr/local/etc/cvsup
*default  prefix=/usr
*default  release=cvs
*default  delete use-rel-suffix



ローカルなcvsupサーバのファイルを覗いてみると、あらら、ちゃんとファイルは存在します。



% ls /home/ncvs/src/sys/modules/coretemp
/home/ncvs/src/sys/modules/coretemp:
Makefile,v   



つまり、ファイルが存在しているのに、cvsupしたとき、そのファイルが取り出されない、そういう状況のようです。



なんとなく、こんなファイルを見つけてしまいました。



% cat sup/src-sys/list.cvs
upgrade src/lkm
upgrade src/sys
omitany src/sys/crypto
omitany */#cvs.*
omitany */,*
omitany */.nfs*
omitany *.core
omitany */CVS



ひょっとして、ファイル名に「core」が入っているファイルは、無視される設定になっている?! と思ったのですが、そんなことはなくて、cvsupしたとき、ちゃんと出てくるファイルがあります。





2~3時間悩んでやっと原因がわかりました。

checkouts.cvs
というファイルが正しくない!



それが原因でした。



# ls -lh sup.client/cvs-all/checkouts.cvs
-rw-rw-r--  1 cvsupin  cvsupin    27M  7 31 06:26 sup.client/cvs-all/checkouts.cvs



あれれ、7月31日以来、更新されていません。



よくわかりませんが、このcheckouts.cvsというファイルに、cvsupでファイル管理するための情報が入ってるらしいです。



ためしに、coretempがあるかgrepしてみると



# grep coretemp sup.client/cvs-all/checkouts.cvs



ないです。



ないので、cvsupしてもでてこない、そういうことのようです。



じゃあなぜないのか・・・それが、cvsup-mirrorの設定ミスというか、運用ミスだったのです。



1ヶ月前、なんだか微妙な設定のファイアウォールが導入されたために、公式cvsupサーバにファイルを取りに行くマシンと、cvsupdを動かすマシンを、別々に分けたのでした(えぇ~何でそんな変なことすんの?!というツッコミ、はい、そのとおり正しいです。私も、こんな妙な構成、納得いかないのです)。



そのため、外にファイルをとりにいく側のsup.client/cvs-all/checkouts.cvsだけ更新されていて、cvsupdが動いているマシンのsup.client/cvs-all/checkouts.cvsは、更新されず、古いままだったのでした。やれやれ。



cvsupdを動かしているマシン側で、sup.client/cvs-all/checkouts.cvsなども、最新へ更新してやった結果、ようやく、coretempが出てきました。



# csup -L 2 cvsup.src-sys
Parsing supfile "cvsup.src-sys"
Connecting to ローカルサーバ
Connected to xx.xx.xx.xx
Server software version: SNAP_16_1h
Negotiating file attribute support
Exchanging collection information
Establishing multiplexed-mode data connection
Running
Updating collection src-sys/cvs
Checkout src/sys/dev/coretemp/coretemp.c
Checkout src/sys/dev/usb/if_zyd.c
Checkout src/sys/dev/usb/if_zydfw.h
Checkout src/sys/dev/usb/if_zydreg.h
Checkout src/sys/modules/coretemp/Makefile
Checkout src/sys/modules/zyd/Makefile
Shutting down connection to server
Finished successfully



2007年9月2日日曜日

杏仁酥(アンニンスウ)風パン

さっき、見つけて買ってきました。メロンパンだと思ったら、なんか微妙に違うんですね。



杏仁酥(アンニンスウ)風パン



200709011



杏仁酥(アンニンスウ)がどういうものか知らなかったんですが、中華のお菓子で、「アーモンド入り中華クッキー」なんだそうです。

・・・ようするに、アーモンドが入ったメロンパンじゃないの?!という感じがしました。



次は、月餅風パンで、ようするにアンパン、ってのが出てくるのでは(笑)



200709012



横濱開港150周年、「濱くら」、「YOKOHAMA HAMAKURA」と書かれていて、「濱」は横浜なんだろうけど、「くら」って何なんでしょうね?




なんか今日になって急に、うちにあるパソコンの、ある1台でだけ、ネットワーク経由のファイルのコピーが非常に遅くなってしまって、非常に、困っています。
USB HDDを抜き差しして、なんとか対処しているんですが、なんとも、めんどくさい!

スイッチングハブを変えてみたり、ネットワークケーブルを変えたり、といった、ごくごく基本的すぎて、ばからしいかもしれないことなんだけど、よくあるトラブルだったりするので、一応確認したけど、関係なし。

「システムの復元」を実行して、たぶんちゃんと動いていた3、4日前のところへ戻したけど、だめ。

問題の原因を切り分けるために、いろいろ試してみてるんですが、どうやら、READだけ遅くなってて、WRITEは正常。つまり、その不調なパソコンへファイルをコピーするときだけ、遅くなっています。一律遅くなるわけじゃなくて、一瞬速度がでるときもあれば、遅くなったりと、バタバタしてるんです。

TCPのプロトコル的な問題で(ウインドウ・サイズとか)、“挙動不審”になってるんじゃないか?!という気がしてるんですが、ちょっとFreeBSDでブートさせて、動作確認してみようかな。



または、別のNICを刺して試してみるか。





焦ると、見えるものも見えなくなる。甘いものでも食べて、ちょっと落ち着いてから、対策を練ろう。




2007年9月1日土曜日

(FreeBSD) portsでビルド中に、undefined reference to `__mulxc3@GCC_4.0.0' というエラー

FreeBSD 6.2-STABLEなマシンで、portsを使って、とあるソフトをビルド中、こんなエラーメッセージが出て終了しました。



/usr/local/lib/gcc-4.2.2/libgfortran.so.2: undefined reference to `__mulxc3@GCC_4.0.0'
/usr/local/lib/gcc-4.2.2/libgfortran.so.2: undefined reference to `__mulsc3@GCC_4.0.0'
/usr/local/lib/gcc-4.2.2/libgfortran.so.2: undefined reference to `__divsc3@GCC_4.0.0'
/usr/local/lib/gcc-4.2.2/libgfortran.so.2: undefined reference to `__muldc3@GCC_4.0.0'
/usr/local/lib/gcc-4.2.2/libgfortran.so.2: undefined reference to `__divdc3@GCC_4.0.0'
/usr/local/lib/gcc-4.2.2/libgfortran.so.2: undefined reference to `__divxc3@GCC_4.0.0'
*** Error code 1



とりあえず、エラーの原因に関係しそうなlibgfortran.so.2をlddで調べてみると、こんな感じで、ちょっと変。



# ldd /usr/local/lib/gcc-4.2.2/libgfortran.so.2
/usr/local/lib/gcc-4.2.2/libgfortran.so.2:
        libm.so.4 => /lib/libm.so.4 (0x281fd000)
        libgcc_s.so.1 => /usr/local/lib/gcc/i386-portbld-freebsd6.2/3.4.6/libgcc_s.so.1 (0x28213000) なんか変だぞ?!
        libc.so.6 => /lib/libc.so.6 (0x2807d000)



gcc-4.2.2のlibgfortran.so.2なのに、gcc-3.4.6のライブラリをリンクするなんて、ありえない感じです。



試しに、他のFreeBSD 6.2-STABLEなホストで確認してみると、こんな風になって、ちゃんとgcc-4.2.2のほうがリンクされてます。



# ldd /usr/local/lib/gcc-4.2.2/libgfortran.so.2
/usr/local/lib/gcc-4.2.2/libgfortran.so.2:
        libm.so.4 => /lib/libm.so.4 (0x881fd000)
        libgcc_s.so.1 => /usr/local/lib/gcc-4.2.2/libgcc_s.so.1 (0x88213000)
        libc.so.6 => /lib/libc.so.6 (0x88086000)



たぶん、こうなるのが正しい姿。





pkg_whichで、ちょっと確認。



# pkg_which /usr/local/lib/gcc/i386-portbld-freebsd6.2/3.4.6/libgcc_s.so.1
[Updating the pkgdb <format:bdb_btree> in /var/db/pkg ... - 1043 packages found (-0 +0)  done]
gcc-3.4.6_1,1



まあ、当然の結果ですね。



ここで、ふと気がつきました。

まてよ、OS標準のGCCって、バージョンはいくつだ?!

# which gcc
/usr/bin/gcc



# gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.6 [FreeBSD] 20060305



/usr/bin/gccは、gcc-3.4.6だ!



で、portsでインストールされたgccは?



# which gcc34
/usr/local/bin/gcc34



# gcc34 -v
Reading specs from /usr/local/lib/gcc/i386-portbld-freebsd6.2/3.4.6/gcc/i386-portbld-freebsd6.2/3.4.6/specs
Configured with: ./..//gcc-3.4.6/configure --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=34 --libdir=/usr/local/lib/gcc/i386-portbld-freebsd6.2/3.4.6 --with-gxx-include-dir=/usr/local/lib/gcc/i386-portbld-freebsd6.2/3.4.6/include/c++/ --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc34 i386-portbld-freebsd6.2
Thread model: posix
gcc version 3.4.6 [FreeBSD]



これも、同じ、gcc-3.4.6だ!

OS標準のコンパイラとして、もともとgcc-3.4.6が入ってるのに、なぜportsでも同じバージョンのgccがインストールされているのだ!?

いったいだれがgcc-3.4.6をインストールさせたのか? /var/db/pkg/gcc-3.4.6_1,1/+REQUIRED_BY を見てみると、たとえばliboilなどが含まれていました



liboilのMakefileを見てみると、こんなのが書かれています。



.if ${OSVERSION} < 600000 && ${OSVERSION} > 500000 && !defined(WITH_3DNOW_GCC40)
BUILD_DEPENDS+= gcc34:${PORTSDIR}/lang/gcc34
RUN_DEPENDS+=   gcc34:${PORTSDIR}/lang/gcc34
CC:=    gcc34
CXX:=   g++34
.endif



FreeBSD 5系のマシンで、liboilなどをインストールしたときに、依存関係でgcc-3.4.6がインストールされるようです。



なるほど、判明しました。



実は、このビルドでエラーが起きてたホストは、つい最近、FreeBSD 5-STABLEから、make buildworld、make installworldなどの手順を経て、FreeBSD 6へアップグレードしたのでした。



だから、



  1. FreeBSD5だったころに、portsでgcc34がインストールされていた。


  2. FreeBSD 6へアップグレードした。


  3. portupgradeしまくった。


  4. もともと入ってたgcc34も、一応、portupgradeされた。


  5. gcc34が入ってたがために、ldconfigで、/usr/local/lib/gcc/i386-portbld-freebsd6.2/3.4.6/が、/usr/local/lib/gcc-4.2.2/よりも先に参照されるように、パスが設定されてしまっていた。


というわけで、



# ldd /usr/local/lib/gcc-4.2.2/libgfortran.so.2
/usr/local/lib/gcc-4.2.2/libgfortran.so.2:
        libm.so.4 => /lib/libm.so.4 (0x281fd000)
        libgcc_s.so.1 => /usr/local/lib/gcc/i386-portbld-freebsd6.2/3.4.6/libgcc_s.so.1 (0x28213000)
        libc.so.6 => /lib/libc.so.6 (0x2807d000)



になってしまうのか。



ということは、portsでインストールしたgcc34を、アンインストールしてしまえばよさそうです。



ただ、gcc34に依存しているパッケージがあったので、まずは、/var/db/pkg/gcc-3.4.6_1,1/+REQUIRED_BY に入っているものすべてportupgrade -fで、再インストールしてみました。



すると、/var/db/pkg/gcc-3.4.6_1,1/+REQUIRED_BY が空っぽになりましたので、安心して、アンインストール。



# pkg_delete gcc-3.4.6_1,1



lddで確認。



# ldd /usr/local/lib/gcc-4.2.2/libgfortran.so.2
/usr/local/lib/gcc-4.2.2/libgfortran.so.2:
        libm.so.4 => /lib/libm.so.4 (0x281fd000)
        libgcc_s.so.1 => /usr/local/lib/gcc-4.2.2/libgcc_s.so.1 (0x28213000)
        libc.so.6 => /lib/libc.so.6 (0x2807d000)



正しそうな状況になっています。



ちなみに最初に、ldconfig -rで確認してれば、どの順番で、共有ライブラリが探されるのかがわかりますね。



/var/run/ld-elf.so.hints:
        search directories: /lib:/usr/lib:/usr/lib/compat:/usr/local/lib:/usr/local/lib/mysql:以下省略





今回はpkg_deleteしてしまうことで解決しましたが、別に、FreeBSD6のマシンにportsでgcc34をインストールして悪いこともないと思います。



ldconfigでのライブラリの検索パスしだいで、おかしな状況になってしまうのが、本当の原因なんじゃないでしょうか? 今回の場合は、libgfortran.so.2が、ライブラリを変なディレクトリからひっぱりこんだのが悪い。



えーと、ldconfigや、LD_LIBRARY_PATHなんかに影響されずに、パスをきめうちでライブラリをリンクする方法があったような気がするんですが、ま、いっか。





なんか重大発表が!?
正直、ちょっとさびしいかも。