Ryzenを積んだマシンで発生した新たな問題とその解決
Ryzenを積んだマシンでgccのビルド負荷をかけるとランダムにSIGSEGVが発生して失敗するという問題に去年ハマりました。これについては問題ない石に取り替えてもらって、解決しました。
satoru-takeuchi.hatenablog.com
ところがその後、マシンが2,3日に一度ハングするという事象が新たに発生して、悩まされておりました。不思議なことに、この事象はSEGVが発生していた石では起きていませんでした。
実はこの事象は上記の記事においては言及していなかったのですが、そこかしこで似たような報告がされていました。報告されている対策はいろいろあって、詳細は下記meihongさんの調査結果が詳しいです。
私の場合は、ここで紹介されていたスクリプトを使ってC6 stateをdisableにしたところ、問題が発生しなくなりました。カーネルのRCUの設定は変更していません。
これについてはハードウェアが悪いのかLinuxが悪いのか全然わかりませんが、あまり気にしないことにします。理由は次の通り。
- 大きな影響なしに回避できる
- SEGV現象に比べると調査しづらい。発生確率が低い上に発生するとマシンがハングする
- 去年ほど時間に余裕が無いし、もう疲れた
色々とトラブルが耐えない石ですが*1、安価でビルドが速いので、これからも数年は頑張ってもらう予定です。
*1:また、今回発生した問題においては犯人が全く不明ですが
リモートマシンのルートファイルシステムをぶっ飛ばした話
はじめに
表題の通り、新年早々やらかしました。備忘録として、あるいは、もしかして誰かの役に立つかもしれないので、事象発生から復旧までの流れをまとめたものを簡単に書いておきます。
1/4 朝: 移動
締め切りが非常に厳しい仕事をかかえる中、自宅から300kmほど離れた場所に移動。作業用マシンにはリモートアクセスできるので仕事には支障なし。の、はずだった。
1/4 夕方: 破壊
目的地に着いて、もろもろ落ち着いたので仕事を開始。テスト用のパーティションに書き込みをする簡単なプログラムを動かしていた。ここでタイプミスしてルートファイルシステムの先頭1GBくらいにランダムなデータを書いてしまうことにより、ぶっ飛ばした。即死はしなかったが、dmesgを見ると案の定カーネル(の中のファイルシステム)のバックトレースが出た上で、ルートファイルシステムが読み出し専用マウントされていた。
余談だが、ここでパーティションをopen()する際にO_EXCLを指定しておけば、マウント中のルートファイルシステムはEBUSYで開けないため、問題は発生していなかった。しかし、わずかな手間を惜しみ、ここをサボった*1。馬鹿じゃないの。
以下、man 2 openより抜粋。
In general, the behavior of O_EXCL is undefined if it is used without O_CREAT. There is one exception: on Linux 2.6 and later, O_EXCL can be used without O_CREAT if pathname refers to a block device. If the block device is in use by the system (e.g., mounted), open() fails with the error EBUSY.
1/4 夕方: リモート復旧の準備
このリモートマシンをなんとかデータを復旧した上で運用継続するにはどうすればいいか、頭をひねった。リモートマシンなのでリブートできないという制約が、なかなかに辛い。
いろいろ考えた末、次のような案を思いついた。
- 空いているパーティションに、作業用のルートファイルシステムを作る
- 1で作ったファイルシステムにchroot
- 破壊されたファイルシステムをumount
- 破壊されたファイルシステムのデータを可能な限りサルベージ*2
- 破壊されたファイルシステム上に、新たなルートファイルシステムを作る
- 5で作ったファイルシステムにchroot
- 定期バックアップデータからルートファイルシステムを復旧
- 死亡直前まで更新していたデータを、4でサルベージしたデータを用いて、出来る限り復旧
1と3のルートファイルシステム作成については次の2つの方法が考えられた。
- debootstrap
- Ubuntu Cloud Imagesからインストール済イメージを持ってきてddでフルコピー
友人たちと相談した結果、aを選択することにした。
どのデータが壊れているかわからないので、いつ死ぬかわからない運試しの作業だが、やるしかない。
1/4 夜: リモート復旧
作業開始。debootstrap起動時に
# deboo
とタイプした後にtabで補完しようとした段階で接続が切れる。即死。多分bash-completionに関するファイルを読もうとしてI/Oエラーによって死んだ。
もうやることがないので、ふて寝。
1/5 朝: 敗走
遠隔地で時間を空費するのはまずいので、自宅に敗走。1週間以上滞在するはずだったのだが、まさかの一日でとんぼ返り。人生は厳しい。
1/5 昼: ローカル復旧
バックアップのあるローカル復旧は、めんどくさいけど、言ってしまえば「やるだけ」。次のような手順で復旧。
- USBメモリにUbuntuインストーラを焼く
- 1で作ったものをlive USBメモリとして使って、起動
- 壊れたルートファイルシステムからデータをサルベージ
- Ubuntuをクリーンインストール
- バックアップデータを新ルートファイルシステムにコピー
- 死亡直前まで更新していたデータを、3でサルベージしたデータから出来る限り復旧
これは、とくに何事もなく成功した。直前まで更新していたソースコードや文書はうまくサルベージできたので、時間と金を浪費した以外に大した実害はなかった。不幸中の幸い。
おわりに
- フェイルセーフ大事
- 二度とやりたくない
- IPMI搭載マシンほしい
Windows10 Fall Creators Update適用後にちょっとした不具合に遭遇
mdadmのヤバそうなバグのCentOSにおける修正状況
はじめに
Ubuntu 16.04のmdadmには、所定の条件を満たすとユーザのデータをぶっ壊すという恐ろしいバグがあります。具体的には次の記事の"バグ1"のことです。
Ubuntuについては一応回避策もありますし、そのうち修正されるでしょうが、「そういえばこれ、CentOSではどうなってるんだろう」と気になったので、CentOS 6.9と7.4についてこのバグの有無を調べてみました。
調査結果
注意: これと同じことがCentOSのクローン元のRHELに当てはまるかどうかは知りません。気になる人はご自身で確認した上で対処してください。間違ってもRed Hat社に「このブログにCentOS 6.9のmdadmに問題があると書いてたからRHELのmdadmを直して」などと言わないようにしてください。Red Hat社にとってはCentOSにバグがあろうとなかろうと「知らんがな」なので。
調査ログ
このバグが存在するかどうかは実機確認すれば一発でわかるのですが、せっかくなのでソースからバグの有無を調査する手順を載っけときます。
CentOS 6.9
まずはソースパッケージのバージョンを次のサイトから調べました。
Index of /6.9/os/Source/SPackages
その中で次の行が見つかりました。
mdadm-3.3.4-8.el6.src.rpm
続いてこのソースrpmをダウンロード&インストールしてソース調査しました。このパッケージの元になっているのはファイル名からわかる通り、upstreamのバージョン3.3.4です。このバージョンは、この問題の修正がまだ適用されていないものです。
さて、これでアウトかと言うと違います。なぜかというと、CentOSなどのディストリビュータが提供するパッケージはupstreamのものにdistro固有のパッチがいくつか当たっていることがあり、それらパッチによって修正されている可能性があるからです。
mdadmのspecファイルを見ると、いくつか独自パッチが当たっていることがわかりました。
... Patch1: mdadm-3.3.4-imsm-don-t-call-abort_reshape-in-imsm_manage_reshape.patch Patch2: mdadm-3.3.4-Grow-close-file-descriptor-earlier-to-avoid-still-in.patch Patch3: mdadm-3.3.4-imsm-abort-reshape-if-sync_action-is-not-reshape.patch Patch4: mdadm-3.3.4-imsm-use-timeout-when-waiting-for-reshape-progress.patch Patch5: mdadm-3.3.4-imsm-don-t-update-migration-record-when-reshape-is-i.patch Patch6: mdadm-3.3.4-Grow-Add-documentation-to-abort_reshape-for-suspend_.patch Patch7: mdadm-3.3.4-super-intel-ensure-suspended-region-is-removed-when-.patch Patch8: mdadm-3.3.4-Grow-close-fd-earlier-to-avoid-cannot-get-excl-acces.patch Patch9: mdadm-3.3.4-Introduce-stat2kname-and-fd2kname.patch Patch10: mdadm-3.3.4-IMSM-retry-reading-sync_completed-during-reshape.patch Patch11: mdadm-3.3.4-The-sys_name-array-in-the-mdinfo-structure-is-20-byt.patch Patch12: mdadm-3.3.4-imsm-add-handling-of-sync_action-is-equal-to-idle.patch Patch13: mdadm-3.3.4-imsm-properly-handle-values-of-sync_completed.patch Patch14: mdadm-3.3.4-Incremental-don-t-try-to-load_container-for-a-subarr.patch Patch15: mdadm-3.3.4-Allow-level-migration-only-for-single-array-containe.patch Patch16: mdadm-3.3.4-imsm-set-generation-number-when-reading-superblock.patch Patch97: mdadm-3.3.2-disable-ddf.patch Patch98: mdadm-3.3.2-udev.patch Patch99: mdadm-3.3-makefile.patch ...
これらのパッチを全部当てた状態のソースを調査しても、バグは修正されていないことがわかりました。つまり、CentOS 6.9は結局アウト。
CentOS 7.4
6.9の場合と同様に、まずはソースパッケージのバージョンを確認しました。
Index of /7.4.1708/os/Source/SPackages
その結果、次のバージョンを使用していることがわかりました。
mdadm-4.0-5.el7.src.rpm
次はこのソースパッケージの調査です。ダウンロード&インストールすると、upstreamのmdadm 4.0がベースとなっていることがわかりました。このバージョンは、バグが修正されているものです。では、これでセーフ確定かというとそうではありません。CentOS固有パッチによってregressionを起こして、またバグが復活している可能性がわずかに残っています。このため、全パッチを適用した上でソース確認しました。確認の結果は問題なかったので、7.4はセーフ。
WSL on Windows 10 Fall Creators Updateの第一印象
Windows10をFall Creators Updateにバージョンアップしてみました。これに伴い、WSLが開発者用のツールではなく、公式アプリとしてMicrosoft Storeから手に入れられるようになりました。さらに、distributionがUbuntuだけでなくopenSUSE, SLESも選べるようになりました。
新版の変更点は次のページにまとまっています。
What’s new in WSL in Windows 10 Fall Creators Update – Windows Command Line Tools For Developers
過去のUbuntu on Windows、および今回追加された3つのディストリビューションアプリごとにデータを独立して持っているので、次のような手順で過去のものから新しいUbuntuにデータを移行しました。
What’s new in WSL in Windows 10 Fall Creators Update – Windows Command Line Tools For Developers
その他、ファイルシステムは過去のものとは異なるどこかに隠されているとMSの人は言っていますが…
What’s new in WSL in Windows 10 Fall Creators Update – Windows Command Line Tools For Developers
実際には<ユーザディレクトリ>/AppData/Local/Packages/<distro用ディレクトリ>/LocalState/rootfs/にあるとわかりました。findで検索したらすぐ見つかりました。
以前次の記事において取り扱った各種性能については、これから計測します。
Windows Subsystem for Linuxとguest/native Ubuntuの性能をざっくりと比較 - Qiita
次のイベントで結果を発表する予定です、乞うご期待。
WSLのファイルシステムイメージをデフォルト以外の場所に移動できるか
WSLのファイルシステムイメージはC:\Users\<ユーザ名>\AppData\Local\lxss
という場所に配置されています。ちょっと理由があって、これを他のストレージ(たとえばDドライブ以下)に移動させたくなったので、できるかどうか調べてみました。結論は、「Fall Creators Updateの時点では(少なくとも公式には)できないらしい」でした。残念。次回以降のrelaseに期待です。
以下調査ログ
とりあえず既存issueの確認をしたところ、あっさりとみつけました。
moving Linux filesystem · Issue #449 · Microsoft/WSL · GitHub
けっこう需要があるのか、はたまた一部の人が熱烈に欲しいのか、スレッドは長いです。最新の情報のほうが多分価値が高いので、調べる時間を短縮するために、新しい末尾の投稿から古い方に順番に読んでいきました。すると、次のようなコメントをみてみました。
moving Linux filesystem · Issue #449 · Microsoft/WSL · GitHub
で、リンクをたどって中身を見ると…
New distros coming to Bash/WSL via Windows Store – Windows Command Line Tools For Developers
確かにMSの中の人のブログとして、次のようなことが書かれていました。
You can install your distros to secondary fixed drives (i.e. not C:!)[Update 2017-07-24: Alas, this didn't fit in the Fall Creators Update schedule; we're looking into this feature for a future release]
非公式なトリッキーな方法を使えばできるかもしれませんが、データがぶっ飛んだら困るので、これ以上深追いするのはやめました。
会社組織を離れて変わったこと
前職を辞めて半年くらい経ちましたので、どういうところが変わったのかを羅列してみました。技術的な話、および、何かのdisり話は無いです。
- 燃え尽きたりはせず、大してやることは変わらなかった。相変わらずOSSに関する何かをごそごそやっている。結局こういうのが好きなんだなあということを再認識
- コードを書くよりドキュメントを書いていることが多い。もしかすると実は後者の方が好きなのかもしれない
- 生活リズムは変化無し。やたら早く起きて早く寝るおじいちゃんスタイル
- 好きなときに好きな場所で、自分のペースで作業できるのは非常に楽。スーパー気分屋なので、とくにそう感じる
- 曜日や祝日の感覚が無くなった。開発MLの流量やtwitterのTL上から知ることが多い
ありきたりですが、盛ってもしょうがないので、こんなところです。日々穏やかに過ごしております。