Coreのdotnetコマンドを試そうとしたら試せなかったの通りハングアップしました。issueを立てて置いていたのですが、その後の話を書きます*1。少々タイトルの範囲が大きいですね。Core公式イメージ実行時に発生した問題ですが、もっと一般的な問題だとわかったのでこうしました。Fusionベース)でも、手持ちのDebianサーバ上に作ったDocker環境でも同じように発生しました。#26というissueを立てましたよという話で終えていました。その後issueを立てた時点で一番疑っていたのはDocker自体です。ホストとのコミュニケーションを多用するメモリ管理かI/Oのどこかでミスっているのだろうという読みでした。その後の手元テストにより、この問題はBoot2Docker(b2d)を新しいバージョン(1.10系)へ上げると発生しなくなることがわかっていました。このためひとまずb2d環境でdotnetコマンド群のテストをおこなっておけば良いか、と考えていました。#18180関連の問題では?というコメントをもらいました。本当の原因(Dockerコミュニティの阿鼻叫喚)このissueは私が見た時点でクローズ済みでしたが、なかなか壮絶で壮大な戦闘録が残っていました。結論をまとめると、これはLinuxカーネル内のmm/filemap.cに対する改善(sendfileシステムコールを利用したデータの書き込み処理で、停止シグナルを受けて途中終了できるようにしたもの)と、Dockerが利用するレイヤードファイルシステムのひとつであるAUFSのデータ書き込み部分の一部に従来のカーネル実装へ依存するコードが存在したことで発生した問題でした。2016年2月末時点で主要ディストリビューションでの対応は終わっており、OSアップデートにより解消します。この問題の解決までを時系列でざっと見てみます。事態は12/21にAUFS内で動作停止に至る具体的な箇所が特定されたのをきっかけに再び動き始めワークアラウンド版の実装、カーネルバージョンを下げる緊急回避策の確立、AUFSの新版を取り込んだカーネルビルド策での対応を経てb2dを含む各ディストリで徐々に新版AUFSの取り込み作業がおこなわれDebianが2/29に3.16.7-ckt20-1+deb8u4を出したことで主要ディストリでの問題対応が収束3ヶ月に及ぶ、長く苦しい戦いだったようです。https://github.com/docker/docker/issues/18180#issuecomment-161843456にてAUFSとmm/filemap.cへの変更によるものだと突き止めているのすごいなと思いました(小並感)。この問題へ取り組み、さっそうとトラブルシュートしつつ更に広い視点からの解決策を模索してAUFSへ潜って本家とやりとりをし、更に主要ディストリ(Ubuntu、Debian)へfix取り込みの働きかけをおこない、それらの状況をトラッキングしissueへ追記していくAkihiroSuda氏まじぱねぇという感想でした。手練というか、なんかNINJA感がありました。いうわけで、私が試した環境2つがたまたま該当してDocker本体の問題と思い込んだのが敗因(?)でしたね。その後、dotnetコマンドは普通にうごきました。立てたissueも先ほどcloseされました。MacBookを4/10に注文、4/14出荷、届いたのは4/17だったので正確にはもうすぐ2ヶ月ですが。Dockerで簡単にGPU対応のTensorFlow入りコンテナを作る方法こんにちは。作品群を読んでいたら連休が終わりそうです。重くなるので読み込まないようにすればOK。資料を補足するシリーズです。途中でやったことや、参考情報を書いていきます。