TOP
Ĥ뤿ˤΥڡ
Xorg 7.2のXサーバで、なぜかxdmでのログイン直後だけ、ctrlキーが効かない。
たしか、Xorg 6.7等の時にも同じ症状にあった気がするが、そのときにどのようにして解決したのか、全く記憶に無い。ここに書いたような気もするが、見つけられなかった。
Xorg 7.2では、xdmのリソースのうち、フォント関連の"Face"を指定しなければいけないらしい。以前の設定のように"xlogin*なんとかFont"だけを指定しても、うまくいかなかった。
最近、FreeBSD/amd64 6-STABLEのホストで、負荷をかけるをクラッシュすることがある。原因不明。しかも、コンパイル中だったりすると、再起動後のバックグラウンドfsckでは修復できないくらいに壊れてしまうらしい。
ところが、このホストにはディスプレイをつないでいないので、手動でfsckをかける方法が無い。どうするか...諸般の事情でディスプレイが余っていないので、困った。
最近、部局のメールサーバがよく止まるが、一方で、メールの重複もかなり多い。原因不明。おそらく、複数のサーバで受け取っているのだと思うのだが、なぜそんなことになるのか？メールサーバくらい、きちんと運用してほしい。そんなこともできないのなら、授業料返せ。
Apacheのログを、毎月1日に別ファイルに保存しなおしている。一旦リネームし、apachectl gracefulしているが、今までは特に問題なく実行できた。
しかし、今月はうまくいかなかったらしい。エラーログを見ると、なぜかいつもよりも再起動に数十秒もの時間がかかっており、実際にはログファイルが保存されていないことが判明した。ファイルをリネームした時点で、なぜか消えてしまったらしい。なぜなのか？原因不明。
ということで、先月分のログがすっかり消えてしまった。
しかも、昨日に何かがおかしいことに気づきながらも、時間がなかったので調査をしなかったため、日曜早朝の毎週一度のバックアップで、先週分のログが残っていたのが上書きされてしまった。
昨日の件で、ふと思い当たることが。そういえばこの前、ついうっかりと、マウント中の/varパーティションにfsckをかけてしまった。何も手を加えなかったつもりだったが、実際には何かしてしまっていたのかもしれない。
[追記]これは誤りでした。see 2007.6.5.
2007.6.1で書いた件は不可解である。ハングアップならともかく、電源が落ちるというのは、電源回りかCPU関連しか思いつかない。
で、ディスプレイを繋いでfsckをかけた。そこでふと気になってBIOSを確認してみる。すると、なぜか無負荷の状態なのに、CPU温度が53℃もある。一月ほど前に別の部屋から移動する前には、クラッシュすることもなかったのだが、そのことの温度は記憶にない。しかし、無負荷で53℃はちょっとおかしい。
そこで、CPUクーラーを取り外して、状態を確認していたが、何も異常は見られない。なんとなく納得できないまま、グリスを拭き取って、新しいグリスを塗り、再度クーラーを装着して、起動してからしばらく経った後の温度を見ると、38℃くらいしかない。
やはり何かおかしかったのか？おかしくなる理由が思いつかないのだが。これが原因だったとすると、CPUの保護のために電源を落としていたということなのだろうか？このマザーボードのBIOSには、そんなメニューはないのだが。FreeBSDから温度をモニタできるといいのだが、あいにくこのマザーボードでの温度計測はできない。
ともあれ、これで無事に動くようになることを願う。
昨日の推測は誤り。問題は、Xorg 7.2への移行にあった。
FreeBSD上では、Xorg 7.2への移行に伴い、/usr/X11R6を/usr/localへのシンボリックリンクにすることになったが、その結果、/usr/local/etc/periodic/と/usr/X11R6/etc/periodic/が同じものを差すことになる。すると、/usr/local/etc/periodic/で実行されたスクリプトが、/usr/X11R6/etc/periodic/としても実行されてしまい、結果として同じスクリプトが全て2回実行されてしまう。
ログのローテーションは全て/usr/local/etc/periodic/の側で行っていたので、その結果として、全てのログについて、5月分が消えてしまった。
これはかなり注意が必要だと思う。これ以外にも、最新の6-STABLEでも同じように重複するものが数多くある。実害のないものもあり、あるいは存在しないといけないものもあるが、注意が必要である。
xdmは起動できるが、一般ユーザでstartxできないこと気にづいた。ちょうど昨日、FreeBSD-users-jp 90742に同じ話が出ていたので、この方法で無事に起動できた。
昨日の件は、本来はmergebase.shで解決される問題らしい。つまり、mergebase.shがきちんと実行されていなかったということのようである。
mergebase.shでは、最初は(たいていは)X11BASEとLOCALBASE以下の重複ファイルをリストアップして、何とかせよ、と言ってくる。それを適当にリネームし、再度実行すると、必要な修正を行ってくれる(行うように指示してくれる?)らしい。
自分で修正してから実行したら、何も起こらなかった。
耐震補修工事のため、研究室の引越しを進めなければならない。そのための情報が、部局のウェブサーバ上にあるらしい。しかし、そこはアクセス制限されている。しかも、いつも使っているパスワードとは異なるパスワードが設定されている。
そこで、こちらで使えるホストのうち、アクセス制限のない唯一のホストで、stoneを使ってポート転送すれば何とかなるかと思って、確認してみた。しかし、転送は行われたが、全く見に覚えのないコンテンツが表示される。いくら確認しても、おかしいまま。stoneでの転送先の指定でホスト名を指定しても、IPアドレスを指定しても変わらない。
どうも、名前ベースのバーチャルホストで運用しているらしい。そのホストでのC NAMEでは、とある研究室のウェブページが運用されているようである。部局の経費で運用されているはずなのに...
で、それはともかく、このような場合にはどのようにしてアクセスすればいいのだろうか？HTTP/1.1でホスト名を指定しなければならないので、このままではどうしようもない。仕方なく、squidを運用して一時的にしのいでいるが、そんなことを強いられるのが不愉快である。
astro/google-earthが必要とするlibGL.so.1はgraphics/linux_driによってインストールされるが、これがよく消えてなくなるようである。以前に書いた気がするが、x11/nvidia-driverでもlibGL.so.1がインストールされるが、これはパスが若干異なるので、これの影響ではないはずである。では、なぜこんなトラブルが繰り返されるのか？
science/xmakemolのビルドに失敗する。
原因は、GL/GLwMDrawA.hが存在しないことによるものらしい。複数ホストで発生するが、send-prされていないし、pointyhatでのビルドではエラーが起きていないらしい。
そこで、誰がこれをインストールするのかを調べてみた。パッケージデータベース以下をgrepしても出てこないので、インストールされているものが消えてしまったわけではないらしい。一方、/usr/ports以下もgrepしてみたが、これをインストールしそうなのは、graphics/libGLwとx11/XFree86-4-librariesくらいである(もちろん、plistを動的に生成するものは検出されていない)。イマドキ、x11/XFree86-4-librariesということはないだろうから、graphics/libGLwを誰かが必要としているのだろうと思ったが、これはほとんど誰にも依存されていない。
ということで、実際にpointyhatでもこのファイルは存在しないはず。しかし、なぜかエラーにならない。何らかのビルドオプションなのかもしれない。もしくは、autoconfなどによるものなのか？
なお、Xorg 7.2より前では、x11/xorg-librariesがこれをインストールしているらしい。
さて、graphics/libGLwをインストールしてから、science/xmakemolをインストールしてみたら、エラーになった。glwMDrawingAreaWidgetClassがない、というものである。ライブラリの相違か。
print/ghostscrip-gplが8.56から8.57にアップデートされた。先日書いた件については、パッチを当てなくても問題なく動くようになったらしい。パッチを見比べてみたが、今ひとつよくわからなかった。
先日、大騒ぎになったトト ビッグ。公表されている情報が事実なら、総売り上げが約14.3億円を超えれば、ほぼ1等がでることになる。また、それより売り上げが増えれば、ますます1等本数が予想される値に近くなるはず。予想される値は5.7億円なので、総売り上げが増えると、6億円は出なくなることになる。
視点を変えると、売り上げが少ないときに当選した人は非常に賞金が少ない可能性があるが、それ以外で1等の当選金は大きく減ることはない。つまり、人数が増えると、当たった人だけが総取りできる、普通のくじと同じである。
なお、期待値だけを見ると、購入額の半分くらいしか帰ってこないことを考えても、やはり普通のくじと変わらない。
ここ数日、SPAMメールが異常に少ない。本当にSPAMメールだけが少ないのか？どこかでメールを取りこぼしている気がする。ある日突然、SPAMメールだけが少なくなる理由が見当たらない。
手元のホストでは、何も異常が記録されていないので、上流の部局サーバでの問題だと踏んでいるが、証拠はない。でも、部局サーバが止まることが多いことを考えると、一番疑わしいのはやはりそちらである。
どうやって調べればいいのだろうか？
ここ数日、SPAMメールが少ないのは、部局サーバの設定が変更されたためらしい。どうも、Message-Id:ヘッダがないメールは、受信しなくなったらしい。
こんなことで効果があるのか？と思って、過去に受信したSPAMメールのヘッダを調べてみると、確かに数通に一通しかMessage-Id:ヘッダがない。結構有効な対策なのかもしれない。
とうとう、引っ越しました。
とはいえ、別の研究室への間借り(というよりも机の場所借り)状態だし、急だったので荷物の選別のろくにせずにすべて持っていったので机の周囲が段ボール箱で埋め尽くされているしで、下の部屋を空にした、というだけの状態である。研究できる状態に戻すにはどのくらいの時間がかかるだろう？
また、このサーバはいつまで使えるのか？
amd(オートマウンタ)でバックアップ用のパーティションをマウントし、バックアップを行っているが、なぜか今日はうまくいかなかったらしい。
まずamdでマウントし、実際にマウントされていることを確認した後、バックアップを実行しているはずなのに、一部がマウント前のパーティションに保存されている。
ディレクトリの更新時刻を確認すると、どうも先にマウント先に作成を始めたものの、途中でアンマウントされてしまったらしい。そのため、大半がマウント前のディレクトリに作成されたようである。その結果、
pdumpfs: No such file or directory - /backup/2007/06/17/root/fooのようなメッセージがログに残っている。
普通は書き込み中のパーティションをアンマウントしないと思うのだが、なぜか強制的にアンマウントされている。amdのログには何もエラーが残っていない。原因不明。
上記に関連して、なぜ/rootが肥大化したのかを見ていると、.ccacheというディレクトリが大きな容量を食っていることに気づいた。約800MB位を消費している。これはまずい。
そこで、これをバックアップ対象から外し、ほかのディレクトリに移動した。こんなものをバックアップする必要はないし、そもそも壊れてもいいものなので、作業ディレクトリ以下に移動しておいた。また、ccacheがこれを適切に使えるように、CCACHE_DIRという環境変数で指定するようにしておいた。
しかしまあ、こんな大きなデータを/rootに作成するのは、犯罪である。大昔のように/の容量が小さいケースでは、致命的だと思う。
2006.3.8で書いたのと同じように、Xorg 7.2で使えるtightvnc-1.3.8_2を作成してみた。
但し、今回はvncviewer以外にも、vncconnectとvncpasswdもamd64バイナリにしている。つまり、Xvncだけをi386バイナリとした。これでうまくいくかどうかは知らないが、今のところは問題ない。また、それに伴い、i386ライブラリもlibjpegだけを含むことにした。
なお、依存性をどうするべきなのか、よくわからなかった。Xorgの膨大なライブラリへの依存性は要らない気がするが、よくわからないので残しておいた。
ダウンロードはこちら(パッケージ名：tightvnc-i386-amd64-1.3.8_2)。
Apacheの認証エラーは、エラーログには残らないのか。
研究室で使っていたPCを自宅に持ち帰って、ADSLモデムに繋いでみた。研究室では固定IPアドレスで使っていたが、自宅のアドレスとは違うので、ADSLモデムからDHCPでアドレスをもらおうと思ったが、なぜかうまくいかない。いつまで経っても「取得中」のままで進展が無い。
それだけではなく、この状態のままで固定アドレスを指定しても、それが有効にならない。このDHCPの「取得中」のままではうまくいかない。ではこれをやめさせる方法は、と考えたが、適切なものが見つからない。インターフェイスを一旦無効にすればいいのだが、もっと適切なものはないのか？
また、DHCPサーバからリースを受けなおす方法も用意されていないようである。Win98のころはwinipcfgでリースの手動更新ができたはずだが、このような機能は無いのか(コマンドを調べる気力がないのだが、きっとそちらにはあるのだろうな...)。
mail/p5-Mail-SpamAssassinをアップデートする。他のportsよりも先に更新して再起動したかったので、これだけをportupgradeすると、razor-agentもアップデートしなければならないらしく、インストールに失敗する。
これは自分の不注意だったのだが、これが原因でportupradeがp5-Mail-SpamAssassinを消し去ってしまう。この挙動が理解できない。明確なバグだが、portupgradeがどのように開発維持管理されているのか、全く分からない。以前にも別のバグの修正をsend-prしたが、相手にされなかった。
初期のころはシンプルでよかったが、なんだか最近はゴテゴテとして重くなっているだけのような気がする。少なくとも、誰が開発しているのか、FreeBSD本体との関係は同なのか、明示してほしい。
p5-Mail-SpamAssassinをportupgradeでアップデート後、/usr/local/etc/rc.d/sa-spamdが起動できない。
[9599] error: Can't locate Mail/SpamAssassin/CompiledRegexps/body_0.pm in @INC (@INC contains: /var/db/spamassassin/compiled/3.002001 /var/d b/spamassassin/compiled/3.002001/auto lib /usr/local/lib/perl5/site_p erl/5.8.8 /usr/local/lib/perl5/5.8.8/BSDPAN /usr/local/lib/perl5/site _perl/5.8.8/mach /usr/local/lib/perl5/site_perl /usr/local/lib/perl5/ 5.8.8/mach /usr/local/lib/perl5/5.8.8) at (eval 571) line 1.といったエラーが出る。
ここ等によると、sa-compileを実行する必要があるらしい。もしくはsa-updateのほうがいいのか。アップデート後のメッセージには
You may wish to run sa-update now to obtain the latest rules.と書かれているが、これが関係しているのか。
で、なぜ今、発覚したかというと、p5-Mail-SpamAssassinが3.20から3.21にアップデートされた際に、
loadplugin Mail::SpamAssassin::Plugin::Rule2XSBodyが有効にされたためらしい。
2007.5.30に書いたように、Samba-3.0.25では、ゴミ箱にファイルを捨てても、きちんとファイルの日付(作成時刻・アクセス時刻)が設定されない。この件についてBugZillaで報告したが、フォローもつかないままに3週間以上が過ぎてしまった。
仕事が一段落したので、ちょっと原因をあたってみる。マクロを通して日付の操作をしているので、どの関数が実体なのかを探るのにずいぶんと時間がかかってしまったが、適当にあたりを付けてデバッグを行った結果、source/modules/vfs_defaults.cのvfswrap_ntimes()がutimes()を使って時刻操作を行っているらしい。エラーはEINVALなので、引数が範囲外、ということなのか。実際に引数を調べてみると、確かにマイクロ秒の数値が10^6を超えている。ファイルの作成時には設定されていない(つまりエラーが起こっていない)ので、ゴミ箱にファイルを捨てる際に設定される現在時刻が不正の原因らしい。
で、よくみると、source/lib/time.cで定義されているtimespec_current()で、ナノ秒の計算が間違っている。本来はマイクロ秒を1000倍すべきなのに、秒数を1000倍している。
これは既に3.0.26に向けて修正が済んでいるらしい。が、これが原因で件のバグが起こったと判断されていないのか、もしくは単に無視されたのか。