hagio.org - 日記

Powered by PENS


Index

2009: 1月(1)(2) 2月(1)(2) 3月(1)(2) 4月(1)(2) 5月(1)(2) 6月(1)(2) 7月(1)(2) 8月(1)(2) 9月(1)(2) 10月(1)(2) 11月(1)(2) 12月(1)(2)
2010: 1月(1)(2) 2月(1)(2) 3月(1)(2) 4月(1)(2) 5月(1)(2) 6月(1)(2) 7月(1)(2) 8月(1)(2) 9月(1)(2) 10月(1)(2) 11月(1)(2) 12月(1)(2)
2011: 1月(1)(2) 2月(1)(2) 3月(1)(2) 4月(1)(2) 5月(1)(2) 6月(1)(2) 7月(1)(2) 8月(1)(2) 9月(1)(2) 10月(1)(2) 11月(1)(2) 12月(1)(2)
2012: 1月(1)(2) 2月(1)(2) 3月(1)(2) 4月(1)(2) 5月(1)(2) 6月(1)(2) 7月(1)(2) 8月(1)(2) 9月(1)(2) 10月(1)(2) 11月(1)(2) 12月(1)(2)
2013: 1月(1)(2) 2月(1)(2) 3月(1)(2) 4月(1)(2) 5月(1)(2) 6月(1)(2) 7月(1)(2) 8月(1)(2) 9月(1)(2) 10月(1)(2) 11月(1)(2) 12月(1)(2)
2014: 1月(1)(2) 2月(1)(2) 3月(1)(2) 4月(1)(2) 5月(1)(2) 6月(1)(2) 7月(1)(2) 8月(1)(2) 9月(1)(2) 10月(1)(2) 11月(1)(2) 12月(1)(2)
2015: 1月(1)(2) 2月(1)(2) 3月(1)(2) 4月(1)(2) 5月(1)(2) 6月(1)(2) 7月(1)(2) 8月(1)(2) 9月(1)(2) 10月(1)(2) 11月(1)(2) 12月(1)(2)
2016: 1月(1)(2) 2月(1)(2) 3月(1)(2) 4月(1)(2) 5月(1)(2) 6月(1)(2) 7月(1)(2) 8月(1)(2) 9月(1)(2) 10月(1)(2) 11月(1)(2) 12月(1)(2)
2017: 1月(1)(2) 2月(1)(2) 3月(1)(2) 4月(1)(2) 5月(1)(2) 6月(1)(2) 7月(1)(2) 8月(1)(2) 9月(1)(2) 10月(1)(2) 11月(1)(2) 12月(1)

今月のアルバム [ 投稿 | 編集 ]


編集

December 2009

Dec 15 (Tue)

21:17

……何だおれは………!! …サーバー 1 台も゛…!!! 救えな゛い゛っ……!!!!

"buggy" hagio

Dec 14 (Mon)

20:31

昨日、新宿南口あたりを歩いていたら、長身でイケメンの金髪外国人がオレの前を歩いていた。 彼はイカした黒い皮のジャケットを着ていて、似合い過ぎだろコンチクショーなどと思っていたら、 右肩の後ろあたりに何やら日本語で書いてあるのに気がついた。気になって近づいてよく見てみると…

 極度乾燥
 しなさい

え???なにそれ??一人ニヤついてしまったじゃないか…。

家に帰って調べてみると、すぐに見つかった。

普通にイギリスのメーカーやん…。しかし、トップページからしてだいぶ日本に影響されているようだ。 取り扱いの注意書きではなく、ブランドロゴに「極度乾燥(しなさい)」って入ってるのがすごい。 スーパードライと言えばビールしか思い浮かばないオレからしてみれば、「極度乾燥」の訳も衝撃的だけど、 「(しなさい)」の必要性が疑問すぎる。しかもカッコ書きになってる意味がまったくわからん。 superdry は基本的には名詞だが、場合によっては動詞にもなりうるってことか??

I superdried my favorite T-shirt.
私はお気に入りの T シャツを極度乾燥させた。
Superdry this!!
これを極度乾燥しなさい!!

それにしても、外国人から見た日本語ってどんな印象なんだろうね。 オレがハングルやアラビア文字を見て感じるものとはまた違うんだろうが、異文化や意味不明なものへの好奇心というか、 独特な面白さを感じるのは一緒なのだろう。もし生まれ変わるとしたら、欧米人になってぜひ日本に来てみたい。

Dec 9 (Wed)

18:47

ちょっと今日は朝から冷や汗ものだった。

昨日、Thunderbird 3 がリリースされたということを知り、 今日朝いちで会社のメーラをバージョンアップしてしまったのだ。 あとで考えるとかなり危険な賭けだったが、好奇心と少しの期待で頭がいっぱいになってしまい、 さらに 4-5 個のアドオンに依存しているということも忘れ、バックアップ取っておけば何か起こっても大丈夫だろうと思って、 朝早く出社してメールのバックアップ (500 MB を超えていた) からバージョンアップまで一気にやってしまった。

バージョンアップ後にそのままではアドオンが一切動かないことに気づき、冷や汗が流れたが、 アドオンをアップデートしたり、強引に xpi ファイルを開いてインストール可能なバージョンを "3.0.*" にしたりすると、 多少の不具合はあるものの、すべてのアドオンが無事に動いてくれた。ふぃ〜、マジ焦ったぜ。

全体的に動作が軽快になっていて、メールの表示やフォルダの切り替えも早くなって、いくぶん快適になった。 ただ、段数の異なる引用部分を一度にコピーすると引用符が 2 倍になる不具合は直っておらず、少しの期待は裏切られたが…。 そういう不具合がないか検索しても見つからないから不思議で、これが直ればほぼ理想的なメーラなんだけど、 かれこれ 1 年くらい不便を強いられている。

ちなみに、オレが依存しているアドオンは以下。もう 1 つあった気がするけどなんだったか忘れた。

絶対必須なのは Ruler Bar だが (いつもお客さん向けのメールを書いているので、 桁数など見栄えには気を使う必要があるため)、オススメは Quicktext ですな。 定型文をマウスやショートカットで入力できて超便利。 いちばん便利なのは罫線の入力で、いろいろな記号・長さの罫線を登録しておくと ババッと線が引けて素早い入力が可能になる。 これに慣れてしまうと、Thunderbird 以外のエディタなんかでも ショートカットを入力してしまうようになるのが欠点だが…。

去年までは EdMax のフリーウェア版を使っていたが、フォルダの容量制限が厳しく、 流量の多いメーリングリストのフォルダなんかは 2 週間毎にローテートしなければならないという状況だったので、 今年の始めに Thunderbird にえいやっと乗り換えた。 フォルダをローテートする必要はなくなったし (あまりに増えると使いにくいのでたまにするが)、 メールにラベリングができたり、アドオンでカスタマイズできたりするのでかなり快適ですよ。

仕事で PC を使っている時間の内訳はおそらく、 メーラ 5 割、ターミナル 4 割、Web ブラウザ 1 割くらいだろう。
一度苦労してでも、いいメーラがあれば乗り換えるべきだと思う。

07:43

見慣れぬメッセージがコンソールに表示されていたのでメモ。VMware 関連っぽい。

vsock: no version for "VMCIDatagram_Send" found: kernel tainted.

Dec 8 (Tue)

19:56

わかります。この季節、家計に占める「みかん代」がバカになりませんよね…。

Dec 2 (Wed)

21:52

家のサーバで、SystemTap の Guru モードを使ってカーネルの中を覗いたりして遊んでたら、 いきなりターミナルが無反応になった。コンソールを見てみるとなぜか普通に再起動が行なわれていて、 何が起こったんだ???と一瞬パニック状態になったが、起動後に /var/log/messages を見てみると以下の一行が。

Dec 2 21:21:19 lab kdump: saved a vmcore to /var/crash/2009-12-02-21:20

オレより先にサーバがパニックしていた模様。これからダンプ解析してみる。

DATE: Wed Dec 2 21:18:55 2009 UPTIME: 01:04:14 LOAD AVERAGE: 0.07, 0.05, 0.00 TASKS: 153 NODENAME: lab.hagio.org RELEASE: 2.6.18-xxx.x.x.el5PAE VERSION: #1 SMP Thu May 7 11:14:31 EDT 2009 MACHINE: i686 (1795 Mhz) MEMORY: 4.5 GB PANIC: "Oops: 0000 [#1]" (check log for details) PID: 9721 COMMAND: "stapio" TASK: f7acd550 [THREAD_INFO: f3afe000] CPU: 0 STATE: TASK_RUNNING (PANIC)

とりあえず、バックトレースを見てみる。

crash> bt PID: 9721 TASK: f7acd550 CPU: 0 COMMAND: "stapio" #0 [f3afedd0] crash_kexec at c0440b6e #1 [f3afee14] die at c04064bc #2 [f3afee44] do_page_fault at c06105c7 #3 [f3afee94] error_code (via page_fault) at c0405a87 EAX: 00000000 EBX: f6887000 ECX: f6887150 EDX: f6887148 EBP: 0000000c DS: 007b ESI: 00000000 ES: 007b EDI: f8d67c11 CS: 0060 EIP: f8d644c7 ERR: ffffffff EFLAGS: 00010296 #4 [f3afeec8] function_get_zone_name at f8d644c7 #5 [f3afeed4] probe_1403 at f8d6728d #6 [f3afeee8] _stp_ctl_write_cmd at f8d67126 #7 [f3afef84] vfs_write at c0471869 #8 [f3afef9c] sys_write at c0471e58 #9 [f3afefb8] system_call at c0404f10 EAX: ffffffda EBX: 00000003 ECX: bf90fe28 EDX: 0000000c DS: 007b ESI: 0000000c ES: 007b EDI: bf90fe28 SS: 007b ESP: bf90fde4 EBP: bf910238 CS: 0073 EIP: 00412410 ERR: 00000004 EFLAGS: 00000293

function_get_zone_name でコケているようだが、これはオレが書いていた SystemTap の C 関数で、 単に zone_table[n]->name を返すだけのものである。これでコケるのがよくわからんが…。 crash を起動したときや sys コマンドで表示される PANIC 行に "check log for details" とあるので、 "log" とコマンドをうってみたら、dmesg のようなものが表示された。

一番下にパニックメッセージが残っていた。

BUG: unable to handle kernel paging request at virtual address 0000121c printing eip: f8d644c7 *pde = 33b6e001 Oops: 0000 [#1] ... CPU: 0 EIP: 0060:[] Tainted: G VLI EFLAGS: 00010296 (2.6.18-xxx.x.x.el5PAE #1) EIP is at function_get_zone_name+0x47/0x69 [stap_c823dc135ff5882bc743757d89f0779b_1516] ... Process stapio (pid: 9721, ti=f3afe000 task=f7acd550 task.ti=f3afe000) ... Call Trace: [] probe_1403+0xce/0x344 [stap_c823dc135ff5882bc743757d89f0779b_1516] ... [] sys_write+0x3c/0x63 [] syscall_call+0x7/0xb ======================= Code: 00 00 00 8d 46 01 89 43 0c 8d 94 1a 48 01 00 00 8b 42 08 8d 4a 08 c7 41 08 00 00 00 00 c7 41 0 c 00 00 00 00 8b 04 85 34 d7 6e c0 <8b> 90 1c 12 00 00 c7 41 0c 00 00 00 00 89 51 08 ff 4b 0c 5b 5e EIP: [] function_get_zone_name+0x47/0x69 [stap_c823dc135ff5882bc743757d89f0779b_1516] SS:E SP 0068:f3afeecc

注目すべきは、最初の一行だろう。

BUG: unable to handle kernel paging request at virtual address 0000121c

仮想アドレス 0x0000121c のページング要求を処理できなかったということらしい。 わかってる人なら、あーなるほど、というレベルのものだということはわかるが、 理解が足りないので宿題としておこう・・。

ちなみに、Oops したときにパニックする設定になっていたためにダンプがとられたようだ。

[root@lab ~]# sysctl -a | grep oops kernel.panic_on_oops = 1

追記
バックトレースやソースから、do_page_fault() でよろしくないアドレスにアクセスしようとしたために Oops してしまったことはわかった。カーネルの変数に直接アクセスしようとしたわけだから 何が起こってもおかしくないというのはわかるが、jiffies は見れるのに zone_table を見れないのはなぜ? しかも仮想アドレス 0x0000121c というのはカーネル空間でもないし…。 実メモリ管理やページフォルトについて勉強し直したが、ピンと来ず。 うむむ、何がわかっていないから理解できないのかがわからない。

11 月(2) へ


↑戻る