5/28 (日) 東京湾を一周してきた。走行距離 203 km
瀬谷の海軍道路〜湘南〜みなとみらい 🚲
4/2 (日) 瀬谷の海軍道路〜湘南〜みなとみらいを走ってきた。ぴったり 100km
多摩川
瀬谷の海軍道路
桜 がみたかったのだが …
nothing ! 花もねぇ つぼみもねぇ なんにもねぇ〜 来週が見頃かね
江ノ島 〜 鎌倉
18号線を南下して江ノ島に着。18号は路肩も広いし交通量もそこまで多くないので非常に走りやすい 🚲
みなとみらい
鎌倉からこぶりな峠をこえて金沢文庫に抜けて、みなとみらいまで向かってゴール
湾岸をうろつきながらクールダウン。途中、何かの映画かドラマかの撮影をやっていたのか 渡部篤郎を見かけた。車の中でじっと座っているだけなのに滲み出るイケメンオーラ。
グッド・チャリズム宣言プロジェクト
輪行でベテラン風のライダーさんと居合わせたので、声をかけてお話をしたのだが「グッド・チャリズム宣言プロジェクト」を運営されているとのことでプロジェクトのあれこれを教えてもらった。
🚲 のマナーや交通ルールの啓蒙につとめているとのことで、ロードに乗り始めてまもない自分でもあれこれ思うところがあるので興味深く お話を拝聴した
山伏峠・正丸峠ライド
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 でハマないように!
設定変更
検証作業なので 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 12月 25 07:32:30 localhost.localdomain systemd[1]: Starting Crash recovery kernel arming... 12月 25 07:32:46 localhost.localdomain kdumpctl[1758]: kexec: loaded kdump kernel 12月 25 07:32:46 localhost.localdomain kdumpctl[1758]: Starting kdump: [OK] 12月 25 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) もついている。次回以降でまとめる
