目次: Linux
サーバでプログラムをmakeすると、挙動が違うことに気づきました。
例えばsed-4.1.5ですと、デスクトップのVM上でコンパイルすると何事もなく成功するのに、サーバでコンパイルするとsed-4.1.5/po以下の *.poファイルを更新しようとして失敗し、コンパイルがコケてしまいます。
デスクトップ、サーバともにDebian GNU/Linux 5.0(Lenny)ですから、コンパイラを始めとしたツールの差はなく、環境変数も同じですし、全く同じソースを利用しています。にも関わらずコンパイルに成功したり、しなかったりするのはなんなのでしょうか?
どうやら使っているツールや環境変数、ソースコードまで同じなのに動作が異なるという現象が起きうるようです。
まずはオーソドックスな手順(※)でコンパイルを進めてみて、違いが出る場所を調べました。configureのログは違いなしですが、makeのログは一行目から既に違っています。
make all-recursive make[1]: Entering directory `/home/katsuhiro/build/sed-4.1.5' Making all in intl make[2]: Entering directory `/home/katsuhiro/build/sed-4.1.5/intl' (... 以下、略 ...)
デスクトップではビルド用のディレクトリ(build/sed-4.1.5)に入って、コンパイルが始まります。
cd /home/katsuhiro/src/sed-4.1.5 && /bin/sh /home/katsuhiro/src/sed-4.1.5/config/missing --run aclocal-1.9 -I config cd /home/katsuhiro/src/sed-4.1.5 && /bin/sh /home/katsuhiro/src/sed-4.1.5/config/missing --run automake-1.9 --gnits doc/Makefile.am:29: docdir was already defined in condition TRUE, which includes condition BUILD_HTML ... (... 以下、略 ...)
対するサーバではソース用のディレクトリ(src/sed-4.1.5)に入って、configureやMakefileの更新が始まります。
なぜこんな違いが出るかというと、ビルドディレクトリのMakefile(build/sed-4.1.5/Makefile)にある、ACLOCAL_M4ターゲットが適用されるか、されないかが異なるためです。
(... 関係ない部分なので略 ...)
48: ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
49: am__aclocal_m4_deps = $(top_srcdir)/config/codeset.m4 \r(... 中略 ...)
60: $(top_srcdir)/config/strverscmp.m4 $(top_srcdir)/configure.ac
(... 関係ない部分なので略 ...)
92: ACLOCAL = ${SHELL} /home/katsuhiro/src/sed-4.1.5/config/missing --run aclocal-1.9
(... 関係ない部分なので略 ...)
260: $(ACLOCAL_M4): $(am__aclocal_m4_deps)
261: cd $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS)
(... 関係ない部分なので略 ...)
一応補足しておくと260行目の定義は「ソースディレクトリのaclocal.m4がconfig/*.m4より古かったら、missing --run aclocal-1.9を実行してね。」という意味です。
つまりデスクトップではaclocal.m4が古いとみなされないのに、サーバではaclocal.m4が古いとみなされるという違いがあるのです。
(※)sedに限らずGNU autotoolsを使ったソースコードをコンパイルする際は、ソースを展開したディレクトリ(例: ~/src/sed-4.1.5)の他に、ビルド用のディレクトリ(例: ~/build/sed-4.1.5)を作成し、ビルド用のディレクトリでコンフィグおよびコンパイル(例: cd ~/build/sed-4.1.5 && ~/src/sed-4.1.5/configure && make && make install)ができます。
どうやらデスクトップとサーバではファイルの新旧が異なるようです。
ではmakeがファイルの新旧をどう判断しているかというと、実はファイルの更新時刻を比較しているだけです。ですからデスクトップではaclocal.m4とconfig/*.m4が同じ更新時刻になっているが、サーバでは更新時刻が異なっていてなおかつaclocal.m4の方が古い時刻になっている、と考えられます。
ファイルの更新時刻はlsコマンドでわかりますが、より詳しい更新時刻を見るためにls --full-timeオプションをつけて調べます。
$ ls --full-time aclocal.m4 config/*.m4 -rw-r--r-- 1 katsuhiro katsuhiro 31965 2009-04-08 21:59:07.000000000 +0900 aclocal.m4 -rw-r--r-- 1 katsuhiro katsuhiro 894 2009-04-08 21:59:07.000000000 +0900 config/codeset.m4 -rw-r--r-- 1 katsuhiro katsuhiro 1394 2009-04-08 21:59:07.000000000 +0900 config/getline.m4 (... 中略 ...) -rw-r--r-- 1 katsuhiro katsuhiro 733 2009-04-08 21:59:07.000000000 +0900 config/strverscmp.m4
デスクトップではナノ秒の部分は全て0に設定されており、どのファイルも同じ更新時間です。
$ ls --full-time aclocal.m4 config/*.m4 -rw-r--r-- 1 katsuhiro katsuhiro 31965 2009-04-08 22:00:53.953952850 +0900 aclocal.m4 -rw-r--r-- 1 katsuhiro katsuhiro 894 2009-04-08 21:59:33.965953865 +0900 config/codeset.m4 -rw-r--r-- 1 katsuhiro katsuhiro 1394 2009-04-08 21:59:33.977953882 +0900 config/getline.m4 (... 中略 ...) -rw-r--r-- 1 katsuhiro katsuhiro 733 2009-04-08 21:59:34.005955390 +0900 config/strverscmp.m4
一方、サーバではナノ秒の部分にも数値が設定されており、どのファイルも異なる更新時間です。
どうやらデスクトップとサーバではファイルの更新時刻が違うらしいことがわかりました。何が原因かというと、実はファイルシステムが違っていたのです。
デスクトップで使用しているReiserFSやext3では、更新時間のナノ秒部分に常に0を代入します。対してサーバで使用しているXFSでは、更新時間のナノ秒部分まできっちり時間を設定します。
結果、ReiserFSやext3上では同時刻と判断されmakeに無視されるようなファイルも、XFS上では更新時刻が異なると判断され、makeがあちこちのファイルを更新して回る現象が起きてしまうわけです。
おそらくtarなどはアーカイブの展開時にutimeで更新時刻を秒単位で上書きしているはずです。XFSに対して更新時刻を秒単位でいじると、同じ時刻に設定したつもりでも、ナノ秒部分が残ってしまって異なる時刻と判断される、なんてことが起きている可能性がありますね。これは追々調べたいと思います。
デスクトップとサーバではファイルシステムが違うせいでmakeの動作が変わることがわかりました。が、問題はそこではなくて、きちんとコンパイルできないのはsedが悪いのであって、ファイルシステムのせいではありません。本来、ReiserFSでもXFSでもコンパイルできないといけないはずです。
しかしコンパイルで問題が出るのは大抵GNU autotoolsやGNU gettextですから、100%sedが悪いとも言えません。こやつらはバージョン間で仕様がメチャクチャに変わりまくるので、ちょっとバージョンが違うとトラブルが起きます(※2)。
結局、悪いのは誰なのか良くわかりません。長々書いたわりに歯切れが悪い…。
(※2)バージョン間の差を理解してさっと直せれば良いのですが、GNU autotoolsやGNU gettextの激変する仕様について行くのは至難の業です。
この記事にコメントする
昨今の投資ブーム(リーマンショック前ですね)に乗っかって投資したは良いものの、金融危機や日本経済のかつてない凋落に直面、今はもう涙が出るばかり…という方はたくさんいるんじゃないでしょうか。
私もその一人でして、調子に乗ってFXに挑戦してみたものの、失敗して15万くらい損を出しました。ここでやめておけば良かったのですが…。
リーマンショック後に「円高の今こそ外貨買いだ!!」と再挑戦したのが運の尽き。買った後も円高が進み(=外貨が下がる)損は増えるばかり。50万以上の含み損をかかえました。
しかもロスカットを嫌って保証金を積み増したため、投資額が雪だるま式に増え、泥沼です。もう損切りする勇気も沸きません。
いい加減な投資は、金を捨てるに等しいですね。
そんなこんなで放置してたFXのポジションですが、株価が徐々に回復し為替も異常な円高から脱出したことで、やや風向きが変わってきました。
あれだけ真っ赤っかに大損こいてたFXのポジションも、なんとか見るに堪える金額になってきました。そろそろ処分すべきだろうなあ。いやはや高い勉強代であった。
この記事にコメントする
ホワイトデーにハンドミキサーを大下さんにプレゼントしたわけですが「普段はハンドミキサーが必要になる料理はしないんですが…。」なんて悲しいことを言われてしまいました。
そんなこと言わないで、せっかく買ったんだし使ってよってことで、ハンドミキサーを使うお菓子をリクエストしました。ババロアです。
私もお菓子作りを手伝いましたが、難しいことはできないので、私は主にハンドミキサー係に。やっぱり大下さんはハンドミキサーをあまり使わないまま、ババロアを作り終わってしまいました。
まあ、いいか。いつか役に立つだろう。うん。
できあがったババロアは冷やしが足りなくて若干ユルユルでしたが、おいしかったです。あと、どのお菓子にも言えるけど、調子に乗ってたくさん作ってはイカン。食いきれないから。
この記事にコメントする
以前サーバとともに(2009年1月14日の日記参照)購入したHDDが5台入るケースですが、2台空きがあったので今回HDDを買い足して埋めました。
今までは1TB HDDが3台入っていました。
真面目にRAID-5を作成すると2TBの容量(HDD 1台1TB * (HDD 3台 - パリティ用HDD 1台) = 2TB)となりますが、私は4台構成(1TB * (4台 - 1台) = 3TB)のRAID-5を作成し、縮退モード(アレイからHDDが1台欠けた状態)で運用していました。
こうすると手持ちのHDDの容量がフルに使えます(1TB HDD 3台で3TBの容量)が、HDDが1台でも故障するとデータが飛んでしまう、耐故障性の低い状態になります。耐故障性のないRAID-5なんて意味がないので、今回2台買い足すに当たって5台構成(1TB * (5台 - 1台) = 4TB)に変更することにしました。
買ってきたHDDを増設したはいいものの、RAIDの再構築には非常に時間がかかります。
縮退モードからRAIDを拡張するには「縮退モードの解消」と「アレイの拡張」の2つの作業が必要です。
まず縮退モードの解消をするため、4台目のHDDをアレイに加えます。すぐにアレイのrebuildが始まります。rebuildが終わると縮退モードが解消されて、4台構成のRAID-5となります。rebuildは20MB/sくらいで進みます(約14時間)。
次に5台目のHDDをアレイに加えます。その後、アレイの拡張を行います。すぐにアレイのreshapeが始まります。reshapeが終わると5台構成のRAID-5が完成します。reshapeは6MB/sくらいしか出ないようです(約48時間)。
以上の手順を踏めばrebuildとreshape 1回ずつで5台構成のRAID-5が完成するはずです。が、私はうまくないことに作業手順を間違え、5台目のHDDをアレイに追加せずにHDD 4台のままアレイを5台構成に変更してしまいました。そのせいで5台構成の縮退モードが構成されてしまいました。
そうすると何が悲しいかっていうと、5台目のHDDを追加するときに再びrebuildが必要になってしまうのです。やり直したくてもreshapeは途中で止められないし、もう待つしかない。む…無念なり。
この記事にコメントする
飲み会の後の朝、うだうだしていたら昼になってました。でもまあどこか行こうかってことで、嵐山に行くことにしました。嵐山は天龍寺(京都府右京区)へ。
このお寺は庭がとても綺麗です。龍安寺の枯山水も良いけど、天龍寺のように池に堂々と水を張るのもいいもんだ…。
桜の時期にしてはやや早いですが、しだれ桜が綺麗に咲いていました。一緒に見ていた大下さんが、この桜を見ていると西行の
願わくば 花の下にて 春死なん
その如月の 望月のころ
という句が思い出される、と言っていました。
さらに大下さんは続けて、如月(2月)の時期に桜は咲かないから「花の下にて」は梅のことかもね、とも言っていました。ふむ…確かに。
この句は西行の辞世の句とも言われています。できれば綺麗な花の下で死にたいな〜って意味と取れば、梅、桜どっちもありかなあ、と思います。
帰りはコロッケだのロールケーキだのを買い食いしながら、ゆったりと歩いて帰りました。今度は桜の時期に行きましょう。
この記事にコメントする
じょーと一緒に飛鳥旅行に行ってきました。歩くととても回りきれないし、疲れちゃうのでレンタサイクルを借りて(1,000円くらい。高いです。)さくさくと回りました。
飛鳥を巡っていると「明日香村」と書いた看板がそこら中にありますが、地名の誤植ではありません。奈良県高市郡の明日香村(あすかむら)なので、これで正しいのです。
欽明天皇陵の近辺です。看板がなければ、田舎によくある小さい神社(吉備姫)と木が生えた低い丘(天皇陵)って感じです。じょーいわく「飛鳥で木が密集している部分があったら、ほぼ古墳だと思って間違いない。」のだそうです。
そういわれてから改めて飛鳥の景色を見ると、木の密集地帯ががくさんあります。つまりそれだけたくさんの古墳があるってこと。さすが奈良、さすが飛鳥。
鬼の雪隠は、丘の上にあった石室が支えを失って、丘から転がり落ちてきたものです。石室のフタだけが丘の上に取り残されています。そちらは鬼の俎と呼ばれています。
亀石です。形が亀に似ているのはわかるけど、何のためにあるのかよくわからない。近くにあった解説版によると、寺の領土の境界点を表していたのではないか?とのこと。目印ってことか。それにしてはでかすぎじゃないか…?
橘寺に行きました。桜は良くて七分咲きってところですかね、満開ではありませんでしたが、とても綺麗です。
橘寺は、手洗い場に「水道水です」トイレに「こぼすまい、一歩前進」など変な看板があって、ちょっと面白いお寺です。訪れた際にはぜひチェック。
石舞台古墳は本来石室を覆っている土が流れたか崩れたかして、石室が地表に出た状態の古墳です。石室ってのは棺桶を入れる部屋のことかな。
石室は地上から見るとこぢんまりしてますが、中に入るとかなり広いことがわかります。石室の主のはずの棺桶はどっかに行ってしまったみたいで、石室内はからっぽです。
次に飛鳥寺に行きました。蘇我馬子(そがのうまこ)が開いたお寺らしいです。お寺にしては珍しく、ご本尊の撮影OKです。嬉々として写真を撮ったはいいけど、堂内は薄暗くてノイズがひどい。携帯カメラじゃだめだ…。
飛鳥寺の敷地の外に蘇我入鹿の首塚があります。首塚を作った当時は首塚も敷地内に入っていたと思われます。というのも、昔の飛鳥寺は飛鳥の大部分を占めるほど広かったのだとか。
最後に甘樫丘に行きました。飛鳥が一望できる小高い丘です。丘の上では桜が2本だけ綺麗に咲いていました。日当たりの良い場所に生えていたのかな。
実は僕らが借りていたレンタサイクルは17時までに返す約束でした。が、甘樫丘を出る時点で既に16時45分です。既に時間通りに返すのは絶望的でしたが、さらにやっちまいました。
レンタサイクル屋のある駅(橿原神宮前駅、かしはらじんぐうまえ)に向かったはずが、なぜか一つ北側の駅(畝傍御陵前駅、うねびごりょうまえ)に着いてしまいました。急いで橿原神宮前駅に戻るもレンタサイクル屋は既にシャッターが降りていて、店員も誰も居ません。
借りた自転車をどうしたものかわからず、レンタサイクル屋に電話すると「店の〜〜に置いといて。」と指示されたので、その通りに放置して帰りました。時間オーバーにも関わらず無事返せたのは嬉しいですが、あんな所に放置して大丈夫かな。
駅に向かうとき、夕暮れの中を自転車で疾走していました。手袋を持ってこなかったことを何度も後悔するほど、寒くて仕方なかったです。最近だいぶ暖かくなってきたと思いますが、夕方は冷えます。まだまだ春は遠いな。
飛鳥旅行の後、土曜も仕事の大下さんと合流して3人で飲み会をしました。
割と奮発して良いワイン(確かNuit Saint Georges、ニュイ・サン・ジョルジュのワイン)と良いチーズ(詳細不明、じょーが買ってきた)を揃えたので、お酒の質は満足満足。
あと、阪神百貨店のお総菜はおいしいわ。ちょっと高いけどなー。
この記事にコメントする
| < | 2009 | > | ||||
| << | < | 04 | > | >> | ||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| - | - | - | 1 | 2 | 3 | 4 |
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | - | - |
wiki
Linux JM
Java API
2002年
2003年
2004年
2005年
2006年
2007年
2008年
2009年
2010年
2011年
2012年
2013年
2014年
2015年
2016年
2017年
2018年
2019年
2020年
2021年
2022年
2023年
2024年
2025年
過去日記について
アクセス統計
サーバ一覧
サイトの情報合計:
本日: