東京湾一周 (時計回り) 🚲

5/28 (日) 東京湾を一周してきた。走行距離 203 km

f:id:hiboma:20170528232617p:plain

続きを読む

河口湖 〜 忍野八海 〜 山中湖 🚲

5/21 (日) 富士山周辺を走ってきた。好天、暑い一日だった。

f:id:hiboma:20170521231626p:plain

相模原方面から甲州街道をぬけて富士吉田にでるコースをとった。走行距離 193km 獲得標高 1786m

続きを読む

小金井公園 〜 多摩川 🚲

5/20 (土) 近所を自転車散歩。夕方に小金井公園多摩川をすいすい

小金井公園

静かな原っぱと森がきもちよい

多摩川

二子玉で夕暮れ

55km ほど走っておわり

f:id:hiboma:20170523115421p:plain

吉見 さくら堤公園 〜 白石峠 〜 秩父 🚲

吉見のさくら堤公園で桜をみて感嘆をあげ、白石峠のヒルクライムで悲鳴をあげてきた

f:id:hiboma:20170410220610p:plain

走行距離 101km 獲得標高は 1080m ほど

続きを読む

瀬谷の海軍道路〜湘南〜みなとみらい 🚲

4/2 (日) 瀬谷の海軍道路〜湘南〜みなとみらいを走ってきた。ぴったり 100km

f:id:hiboma:20170403105549p:plain

多摩川

瀬谷の海軍道路

桜 がみたかったのだが …

nothing ! 花もねぇ つぼみもねぇ なんにもねぇ〜 来週が見頃かね

江ノ島 〜 鎌倉

18号線を南下して江ノ島に着。18号は路肩も広いし交通量もそこまで多くないので非常に走りやすい 🚲

みなとみらい

鎌倉からこぶりな峠をこえて金沢文庫に抜けて、みなとみらいまで向かってゴール

湾岸をうろつきながらクールダウン。途中、何かの映画かドラマかの撮影をやっていたのか 渡部篤郎を見かけた。車の中でじっと座っているだけなのに滲み出るイケメンオーラ。

町中華街駅から輪行で帰宅

グッド・チャリズム宣言プロジェクト

輪行でベテラン風のライダーさんと居合わせたので、声をかけてお話をしたのだが「グッド・チャリズム宣言プロジェクト」を運営されているとのことでプロジェクトのあれこれを教えてもらった。

good-charism.com

🚲 のマナーや交通ルールの啓蒙につとめているとのことで、ロードに乗り始めてまもない自分でもあれこれ思うところがあるので興味深く お話を拝聴した

山伏峠・正丸峠ライド

12/29 山伏峠と正丸峠をのぼってきた

2016年最後の自転車

名栗湖

謎の壁画前でぱちり

山伏峠

平均 6-7% ほどで距離も短く20-30分もあればのぼりきれる 小ぶりな峠 (早い人は十分台で登れるぽい)

小ぶりだけども、道路の状態が良く、大きく蛇行するカーブが連続していて、暗い杉林を越えたり急坂に建つ民家がみえたり、景色が常に変化するので飽きない

最後に 11-12% のカーブがあるので そこを踏ん張れたらゴール

峠に達しても景色がイマイチなのが惜しい(景色を求めるなら正丸峠に行こう)

正丸峠

山伏峠に来たら消化試合的に正丸峠ものぼる

さすがにお茶屋は閉店している

遠くに新宿の高層ビル群が見える。iPhone のカメラでは捉えられない 📷

芦ヶ久保

帰りは電車。秩父まで降りたかったけど、時間が無いので芦ヶ久保から輪行。寒くて指がかじかんで袋詰めが大変

1時間半ほどで最寄り駅に到着。お疲れ様でした

ミドルウェア: abrtd (2)

前回の続き 。abrtd で カーネルパニック時の vmcore を採取する

まとめ

検証作業をしてみた結果、正確には、

  • kdump が起動していて、
  • カーネルパニック後に kdump で vmcore を採取できた場合、
  • 再起動後に vmcore + 予備情報を /var/crash 以下にまとめてくれる

と理解した。abrtd が全部よしなにやってくれると思ってしまったが、vmcore を採取するのは kdump の仕事だった。

kdump の設定

kdump.service の準備が必要。 Red Hat のドキュメントを読もう

Red Hat Enterprise Linux - カーネルクラッシュダンプガイド - 2.2. コマンドラインで KDUMP を設定する

tips: Vagrant + CentOS7 で試す場合

crashkernel=auto でハマないように!

repl.info

設定変更

検証作業なので grub2 設定をシェルで書き換えていく

$ sudo systemctl enable kdump.service
$ sudo perl -i'.bak' -nlpe 's/crashkernel=auto/crashkernel=128M/' /etc/default/grub 
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
$ sync
$ sudo reboot

reboot 後に kdump の status を確認しよう

$ sudo systemctl status kdump
● kdump.service - Crash recovery kernel arming
   Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)
   Active: active (exited) since 日 2016-12-25 07:32:46 EST; 14h ago
  Process: 1758 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
 Main PID: 1758 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/kdump.service

1225 07:32:30 localhost.localdomain systemd[1]: Starting Crash recovery kernel arming...
1225 07:32:46 localhost.localdomain kdumpctl[1758]: kexec: loaded kdump kernel
1225 07:32:46 localhost.localdomain kdumpctl[1758]: Starting kdump: [OK]
1225 07:32:46 localhost.localdomain systemd[1]: Started Crash recovery kernel arming.

カーネルパニックを起こす

kdump の用意ができたら echo c > /proc/sysrq-trigger秘孔を突いて カーネルパニックを起こす

$ echo c | sudo tee  /proc/sysrq-trigger

VM が再起動した後に、ログインして abrt-cli でレポートを一覧する

不備が無ければ BUG: unable to handle kernel NULL pointer dereference at (null) がキャッチされているはず

$ sudo abrt-cli ls
id 5f8ee8234bfdd61810b08d481291fa5d07ef4a6d
reason:         BUG: unable to handle kernel NULL pointer dereference at           (null)
time:           Sun Dec 25 21:50:39 2016
uid:            0 (root)
count:          1
Directory:      /var/spool/abrt/vmcore-127.0.0.1-2016-12-25-07:38:42
Reported:       cannot be reported

/var/spool/abrt 以下には下記のようなデータが採取されている

$ sudo ls -hal /var/spool/abrt/vmcore-127.0.0.1-2016-12-25-07:38:42
total 33M
drwx------. 2 root root 4.0K Dec 25 21:51 .
drwxr-x--x. 5 root abrt 4.0K Dec 25 21:50 ..
-rw-------. 1 root root    6 Dec 25 21:50 analyzer
-rw-------. 1 root root    6 Dec 25 21:50 architecture
-rw-------. 1 root root 2.9K Dec 25 21:50 backtrace
-rw-------. 1 root root    6 Dec 25 21:50 component
-rw-------. 1 root root    1 Dec 25 21:50 count
-rw-------. 1 root root    0 Dec 25 21:50 event_log
-rw-------. 1 root root   25 Dec 25 21:50 kernel
-rw-------. 1 root root   76 Dec 25 21:50 kernel_tainted_long
-rw-------. 1 root root    3 Dec 25 21:50 kernel_tainted_short
-rw-------. 1 root root   10 Dec 25 21:50 last_occurrence
-rw-------. 1 root root  135 Dec 25 21:50 machineid
-rw-------. 1 root root  131 Dec 25 21:50 not-reportable
-rw-------. 1 root root  393 Dec 25 21:50 os_info
-rw-------. 1 root root   38 Dec 25 21:50 os_release
-rw-------. 1 root root   73 Dec 25 21:50 reason
-rw-------. 1 root root    4 Dec 25 21:50 runlevel
-rw-------. 1 root root   10 Dec 25 21:50 time
-rw-------. 1 root root    6 Dec 25 21:50 type
-rw-------. 1 root root    1 Dec 25 21:50 uid
-rw-------. 1 root root    5 Dec 25 21:50 username
-rw-------. 1 root root   40 Dec 25 21:50 uuid
-rw-------. 1 root root  33M Dec 25 07:38 vmcore
-rw-------. 1 root root  35K Dec 25 07:38 vmcore-dmesg.txt

それぞれのファイルの詳細は https://gist.github.com/hiboma/431d0a5e3e8fe8a1a2b699a71e61abf9 にまとめた。vmcore が取れていれば crash を使って原因の解析ができる

vmcore が残る

ところで /var/crash 以下にも kdump が採取した vmcore が残っている

# /var/crash 
$ sudo ls -hali /var/crash/127.0.0.1-2016-12-25-07\:38\:42/vmcore
310061 -rw-------. 1 root root 33M Dec 25 07:38 /var/crash/127.0.0.1-2016-12-25-07:38:42/vmcore

# /var/spool/abrtd にも残ってる
$ sudo ls -hali /var/spool/abrt/vmcore-127.0.0.1-2016-12-25-07:38:42/vmcore
19216963 -rw-------. 1 root root 33M Dec 25 07:38 /var/spool/abrt/vmcore-127.0.0.1-2016-12-25-07:38:42/vmcore

vmcore のサイズが大きい場合に、内容が同じ vmcore が重複するのはもったいない。設定で回避できるだろうか?


abrtd にはクラッシュをレポートする機能 (libreport) もついている。次回以降でまとめる