つい先日、VirtualBox上にCentOS7の環境を作りkdumpが動作するか確認しました。するとCentOS 7.0～7.6まで（症状が多少違うところもありますが）全て失敗したので、CentOSでkdumpが動かないものだと判断してしまいました。
しかしWeb上で見つけた情報「カーネルクラッシュダンプの基本や取り方など」によると、CentOS 7.6でkdumpが動いているようです。それならばVirtualBoxで動かないのは、CentOSの問題ではなく、VirtualBoxの問題ということになります。
試しにVMware Workstation Player上にCentOS7の環境を作って、kdumpの実験をしてみました。するとkdumpが動くのです。やはりCentOSの問題ではなく、VirtualBoxの問題だったのでしょう。しかし未だに疑問なのは、VirtualBoxでkdumpできないのは、僕だけなのか、世間一般でそうなのかという事です。VirtualBoxの既知のバグで動かないのであれば、将来のバージョンで動くようになるかもしれません。しかし、何か設定をすることでkdumpできるようにするTipsがあるのであれば、ぜひ知りたいと思います。
それにしても、何が問題なのか情報がないと、調査の糸口も掴めません。CentOSは、旧いOSのように起動時にメッセージがズラズラと出てこないので、何が悪いのか判断する情報が得られないのです。昔は起動時に長々とメッセージがコンソールに流れていましたが、一般受けしないので出さなくする傾向にあるのだと思います。
なんとか情報が得られないかと調べていたら、GRUB2のブートメニューで編集モードに入り、パラメータを変えれば良いようです。パラメータ「rhgb quiet」の指定を消せば昔のOSのように起動ログが出てくるようになります。また更に詳しい情報が必要ならパラメータ「loglevel=7 systemd.log_level=debug」を指定すれば、もっと詳しく情報が出てきます。
この指定をおこなってVirtualBoxでkdumpを起動しようとしたところ、2nd kernelの起動ログが出る前にVirtualBox自体が落ちてしまいました。そもそも2nd kernelに制御が渡っていないようです。
2019-08-30
2019-08-26
「電撃戦」と「鎖国」
岩波新書の『独ソ戦』（大木毅）を読んでいます。独ソ戦というのは歴史として知っていますが、より踏み込んだ内容については詳しく知りません。まだ読んでいる最中ですが、これまでの理解が正しいとは言えなかったことを知りましたし、最新の研究成果を反映しているので、より正確な理解ができると期待しています。
なかでも驚いたのが、以下の記述です（47頁）。
第二次世界大戦当初のドイツ軍の快進撃は「電撃戦」として解説されることが多いと思っていましたが、ドイツ軍の軍事的な原則ではなかったというなら驚きです。通俗的な歴史理解は、実は歴史的な正確な理解とは限らないという事なのでしょうか。
そこで思いだすのが、日本史で耳にする「鎖国」です。通俗的な日本史では江戸時代は「鎖国」と言われますが、歴史研究者からは「鎖国」などは無く、「海禁」と理解されるという見解も出ています。
当たり前だと思っていた歴史理解が、実はそうではないという事例は、他にもありそうです。
なかでも驚いたのが、以下の記述です（47頁）。
「電撃戦」という単語自体、第二次世界大戦前半の一連の戦役ののちに、外国のジャーナリスト、あるいはプロパガンダ当局が用いはじめたもので、軍事用語ではなかったことを解明している。
第二次世界大戦当初のドイツ軍の快進撃は「電撃戦」として解説されることが多いと思っていましたが、ドイツ軍の軍事的な原則ではなかったというなら驚きです。通俗的な歴史理解は、実は歴史的な正確な理解とは限らないという事なのでしょうか。
そこで思いだすのが、日本史で耳にする「鎖国」です。通俗的な日本史では江戸時代は「鎖国」と言われますが、歴史研究者からは「鎖国」などは無く、「海禁」と理解されるという見解も出ています。
当たり前だと思っていた歴史理解が、実はそうではないという事例は、他にもありそうです。
2019-08-23
カーネルがパニックしても再起動がかからない
Linuxにおいて、コマンドラインから意図的にカーネル・パニックを発生させる方法があります。Webを検索すれば情報はすぐに見つかると思います（例えば「sysrqキーでパニックさせる」がそうです）。Linuxであれば、Ubuntuであろうが、openSUSEであろうが、CentOSだろうが、ディストリビューションを選ばないと思っていました。ところがそうでもないようです。
発端はCentOS 7.4でした。カーネルがパニックを起こしたら自動的に再起動するような設定にした筈なのに、実際にパニックを起こしているようであるのに、再起動しないのです。その時点で、マシンへのpingは通りませんし、コンソール画面には何も映っていません。もう電源を手動で落とすしかない状態です。
実際に運用中の環境で「パニックの実験」は出来ませんから、VirtualBox上にCentOS 7.4の最低限の環境を作って試してみました。するとやはり再起動しないのです。現象は再現したと言えるのかもしれませんが、もしかすると何か手順を間違えているのかもしれません。そこで、VirutalBox上で動作するように準備しているUbuntu 18.04やopenSUSE 13.1で試してみました。するとどちらもカーネルがパニックすると再起動します。手順に誤りは無いと判断して良いでしょう。
Webには「CentOS7.0でカーネルパニックを発生させてみる」という情報があるのです。CentOS 7.0なら再起動して、CentOS 7.4では再起動しないというのも不思議な話です。そこでVirtualBox上にCentOS 7.0から7.5までの各環境を準備して、再起動されるか否かを実験してみました。その結果、驚いたことに再起動したと言えるのはCentOS 7.1だけでした。
CentOS 7.4で再起動されない現象は確認できましたが、運用上の理由から再起動して欲しいのです。システムパラメータに何か関係しそうな設定があるのかもしれないと考えてCentOS 7.3とCentOS 7.4を比較してみましたが、それらしい設定はなさそうです。
解決策が見出せないまま手詰まりかと思ったのですが、ふと「kdumpが再起動を邪魔しているのではないか」と思いつきました。カーネルがパニックするとkdumpでクラッシュダンプを取得することになるので、kdumpが居なければ再起動できるのではないかと考えたのです。そこで確認してみるとCentOS 7.0以降の全バージョンでkdumpサービスが動いていました。
コマンドラインから「systemctl stop kdump」でサービスを止めて、当初の手順でカーネル・パニックを起こしてみると、なんとCentOS7.4でも再起動しました。やはりkdumpが邪魔していたのでしょう。
発端はCentOS 7.4でした。カーネルがパニックを起こしたら自動的に再起動するような設定にした筈なのに、実際にパニックを起こしているようであるのに、再起動しないのです。その時点で、マシンへのpingは通りませんし、コンソール画面には何も映っていません。もう電源を手動で落とすしかない状態です。
実際に運用中の環境で「パニックの実験」は出来ませんから、VirtualBox上にCentOS 7.4の最低限の環境を作って試してみました。するとやはり再起動しないのです。現象は再現したと言えるのかもしれませんが、もしかすると何か手順を間違えているのかもしれません。そこで、VirutalBox上で動作するように準備しているUbuntu 18.04やopenSUSE 13.1で試してみました。するとどちらもカーネルがパニックすると再起動します。手順に誤りは無いと判断して良いでしょう。
Webには「CentOS7.0でカーネルパニックを発生させてみる」という情報があるのです。CentOS 7.0なら再起動して、CentOS 7.4では再起動しないというのも不思議な話です。そこでVirtualBox上にCentOS 7.0から7.5までの各環境を準備して、再起動されるか否かを実験してみました。その結果、驚いたことに再起動したと言えるのはCentOS 7.1だけでした。
- VirtualBoxがダイアログを出し、仮想マシンが落ちてしまう（CentOS 7.0、CentOS 7.2、CentOS 7.3）
- 画面が固まり、再起動しない（CentOS 7.4、CentOS 7.5）
CentOS 7.4で再起動されない現象は確認できましたが、運用上の理由から再起動して欲しいのです。システムパラメータに何か関係しそうな設定があるのかもしれないと考えてCentOS 7.3とCentOS 7.4を比較してみましたが、それらしい設定はなさそうです。
解決策が見出せないまま手詰まりかと思ったのですが、ふと「kdumpが再起動を邪魔しているのではないか」と思いつきました。カーネルがパニックするとkdumpでクラッシュダンプを取得することになるので、kdumpが居なければ再起動できるのではないかと考えたのです。そこで確認してみるとCentOS 7.0以降の全バージョンでkdumpサービスが動いていました。
コマンドラインから「systemctl stop kdump」でサービスを止めて、当初の手順でカーネル・パニックを起こしてみると、なんとCentOS7.4でも再起動しました。やはりkdumpが邪魔していたのでしょう。
2019-08-15
小平尚道『アメリカ強制収容所』を読んで
雑誌「ナショナルジオグラフィック（日本版）」の2018年10月号を読んでいたら（定期購読しているので毎月郵送されてきているのですが、忙しくて読む時間がとれずに溜まっています。時間をみつけて、読んでいる最中なのですが）、「強制収容された日系人」という記事がありました。話題がそれますが、この記事のタイトルがこれで正しいのか不明です。というのは、目次にあるタイトルは、先述したようになっていますが、本文にはそれらしいタイトルがなく、タイトルらしきものとして「私はアメリカ人です。戦時中の日系人強制収容が今の米国に問いかける。」とあるだけなのです。
閑話休題。第二次世界大戦中のアメリカにおける日系人強制収容については、話には聞いていましたが、詳しく知りません。1980年頃になってからアメリカ政府が誤りを認め謝罪したとの話も聞いたことがありますが、詳しく理解している訳ではありません。
まずは参考になるような書籍を読んでみようと図書館で調べてみたら『アメリカ強制収容所―戦争と日系人―』（小平尚道、1980年）というのがあったので借りてきて読んでみました。著者である小平尚道は、1912年に米国生まれの日系二世で、シアトル長老教会牧師でした。日系人として強制収容された体験者です。本書は、その体験記であり、アメリカにおける日系人強制収容の全貌を明らかにしているわけではありません。本書の序文で著者が以下のように記しているとおりです。
著者は日米開戦前の1940年夏から秋にかけて日本を訪れ、満州にも行ったことが、まず最初に記されています。本書の基調は体験談なので、その時に著者の身に何があったのか、また著者が当時の日本の状況をどのように見ていたのか、そして日米の違いをどう感じていたのか等に主眼をおいて記されています。その内容は著者の主観ですから、それを割り引いて理解する必要がありますが、その反面として著者の関心の在りかや感想を通して、当時の社会をより深く知ることができます。これはとても興味深いことで、無味乾燥な教科書の（可もなく不可もなく、と言った）淡々とした記述に比べると、説得力があると感じました。
閑話休題。第二次世界大戦中のアメリカにおける日系人強制収容については、話には聞いていましたが、詳しく知りません。1980年頃になってからアメリカ政府が誤りを認め謝罪したとの話も聞いたことがありますが、詳しく理解している訳ではありません。
まずは参考になるような書籍を読んでみようと図書館で調べてみたら『アメリカ強制収容所―戦争と日系人―』（小平尚道、1980年）というのがあったので借りてきて読んでみました。著者である小平尚道は、1912年に米国生まれの日系二世で、シアトル長老教会牧師でした。日系人として強制収容された体験者です。本書は、その体験記であり、アメリカにおける日系人強制収容の全貌を明らかにしているわけではありません。本書の序文で著者が以下のように記しているとおりです。
したがって、私の経験はミネドカ収容所に限定され、これを一般化することはできない。あくまで私個人の体験で、どこの収容所も、こうだったとは言えない。それ故、この本はアメリカ収容所の全体を画いたものでなく、その一部を録したものにすぎない。
著者は日米開戦前の1940年夏から秋にかけて日本を訪れ、満州にも行ったことが、まず最初に記されています。本書の基調は体験談なので、その時に著者の身に何があったのか、また著者が当時の日本の状況をどのように見ていたのか、そして日米の違いをどう感じていたのか等に主眼をおいて記されています。その内容は著者の主観ですから、それを割り引いて理解する必要がありますが、その反面として著者の関心の在りかや感想を通して、当時の社会をより深く知ることができます。これはとても興味深いことで、無味乾燥な教科書の（可もなく不可もなく、と言った）淡々とした記述に比べると、説得力があると感じました。
2019-08-10
映画「スティング」
NHK BSプレミアムで2019年8月15日の午後1時から映画「スティング」が放送される予定です。NHKのサイトでは、次のように紹介しています。
ギャングのボスをだまそうとする詐欺師の話だとは思っていましたが、「コメディー」とは考えていませんでした。娯楽映画だとは思うし、実録もののドキュメンタリーではないですし、観終わったときに暗い気持ちになる訳ではないので、すっきりする楽しい映画だとは思います。
しかし「コメディー」と言われると、そうなのかなぁと思います。コメディ映画に出演しているポール・ニューマンやロバート・レッドフォードは「コメディアン」という事になってしまうのでしょうか。
Ｐ・ニューマン、Ｒ・レッドフォード、Ｇ・Ｒ・ヒル監督、「明日に向って撃て！」の名トリオが、１９３０年代のシカゴを舞台に、仲間の復しゅうのため、ギャングの大親分に挑む詐欺師たちの華麗で大胆な活躍を描く傑作犯罪コメディー。（以下略）
ギャングのボスをだまそうとする詐欺師の話だとは思っていましたが、「コメディー」とは考えていませんでした。娯楽映画だとは思うし、実録もののドキュメンタリーではないですし、観終わったときに暗い気持ちになる訳ではないので、すっきりする楽しい映画だとは思います。
しかし「コメディー」と言われると、そうなのかなぁと思います。コメディ映画に出演しているポール・ニューマンやロバート・レッドフォードは「コメディアン」という事になってしまうのでしょうか。
2019-08-09
rsyncで除外指定（--exclude）の問題が解決した
dynabook SS SX/15AにNetBSD/i386を入れて利用しています。この他に、日常的に使用しているデスクトップPCがあり、それはWindow10です。Windowsのフォルダ「Documents」にあるファイルをNetBSD側にコピーしておけば、ノートPCを持って出かけた時に参照できて便利だと思うので、同期させておこうと考えています。ただしdynabookのディスク容量が厳しいので、出先では無用なファイルは同期対象から外したいと思っています。
まず同期する仕組みはrsyncを使います。Windows10上のWSLを利用すれば、U*IX系の各種ツールが利用できるため、Win32版rsyncなどを利用するよりも安心できます。rsyncを利用してファイルを同期することは、あまり苦労することもなく出来ました。
やっかいだったのが、除外対象を除いて同期させることです。rsyncで除外対象を指定するにはオプション「--exclude」を指定すればよいようなのですが、指定方法に癖があり、苦労している情報がWebには溢れています。Webで見つけた以下の情報を参考にしました。
最終的に期待する動作をするようになったのですが、うまくいかなかった原因はrsyncのオプションの指定方法ではなく、自作したシェルスクリプトの書き方の問題でした。
当初シェルスクリプトでは次のように書いていました。除外対象は今後増減する可能性がありますし、rsyncに指定するオプションは他にもあるので、それを分離したつもりでした。
まず同期する仕組みはrsyncを使います。Windows10上のWSLを利用すれば、U*IX系の各種ツールが利用できるため、Win32版rsyncなどを利用するよりも安心できます。rsyncを利用してファイルを同期することは、あまり苦労することもなく出来ました。
やっかいだったのが、除外対象を除いて同期させることです。rsyncで除外対象を指定するにはオプション「--exclude」を指定すればよいようなのですが、指定方法に癖があり、苦労している情報がWebには溢れています。Webで見つけた以下の情報を参考にしました。
最終的に期待する動作をするようになったのですが、うまくいかなかった原因はrsyncのオプションの指定方法ではなく、自作したシェルスクリプトの書き方の問題でした。
当初シェルスクリプトでは次のように書いていました。除外対象は今後増減する可能性がありますし、rsyncに指定するオプションは他にもあるので、それを分離したつもりでした。
EXC_OPTS="しかし期待した動作をしない原因は、この指定にあったようです。以下の書き方をすると、期待した動作をするようになりました。違いは、オプションの中でシングルクォートで括っているのを止めたことです。
--exclude='*.[eE][xX][eE]'
--exclude='*.[jJ][pP][gG]'
"
EXC_OPTS="この解決に至る過程で、rsyncのオプション「-vvv」を利用しました。文字「v」を増やすほど情報が増えるようです。そこに以下のような出力が現れているのが確認できます。除外対象が期待した通りに処理されていれば、このような出力になるはずです。うまく指定されていなければ、「because of pattern」という表示がなく、除外対象にしている筈なのに、なぜか同期対象とされてしまい、頭を捻ることになります。
--exclude=*.[eE][xX][eE]
--exclude=*.[jJ][pP][gG]
"
[sender] hiding file a/b/c/1.jpg because of pattern *.[jJ][pP][gG]問題の原因がわかってしまえば、至極当然なことと思えますが、解決できていないときには、五里霧中という気持ちになります。ともかく解決できて、一安心しました。
2019-08-05
Microsoft Windows 10からNetBSD/i386へのDocumentsフォルダの同期にrsyncを利用する
dynabook SS SX/15AのOSをNetBSD/i386に入れ換えて利用しています。日常的に利用しているのはMicrosoft Windows 10のデスクトップPCです。ここにあるDocumentsフォルダをdynabook側にもコピーしておくことで、出先にdynabookを持っていた時、ファイルを参照できる環境となるようにしています。
元々はdynabookにはMicrosoft Windows Vistaが入っていたので、ファイルを同期するのは簡単でした。共有フォルダとして見えるようなっていれば、XCOPY.EXEを利用してファイルをコピーできました。
Vistaがフェーズアウトし、OSをNetBSDに入れ換えたことにより、同期する仕組みを工夫する必要が出てきました。うまい仕組みを作り上げたと思っても、動作が不安定で、なかなか満足のいくものになりませんでした。
そうこうしているうちに、Microsoft Windows 10でWSL（Windows Subsystem for Linux）が利用できるようになりました。WSLを使えば、Windows側のファイルをWSL側から参照することができます。しかも本物のLinuxディストリビューションを利用できるので、U*IX系OSとしてNetBSDとの親和性も高く、同期方式が作りやすくなります。
結局、WSL上でrsyncを使って、ローカルにあるDocumentsフォルダのファイルを、リモートにあるNetBSD上の所定のディレクトリにコピーすることにしました。試しに動かしてみると、上手くいっています。この点では成功と言えるでしょう。
ただし問題もあります。dynabook SS SX/15Aのディスクは60Gしかないので、OSやアプリケーションを入れた後で使える容量は、あまり残っていません。Windows側のDocumentsフォルダにあるものを全てコピーしてしまうと、ディスクが溢れる恐れがあります。そこで余分なファイルはコピーしないようにしたいところです。
このような要望のために、rsyncにはオプション「--exclude」が用意されており、これを使えば解決と言いたいところです。ところが指定方法が難しく、指定してみても、期待した動作をしません（要するに、コピー対象から除外したつもりなのに、コピーされてしまう）。Webを検索しても、うまくいかずに苦労している人達が溢れています。
コピーは出来ているので、ひとまず成功と言えるのですが、コピー除外がうまくいっていないので、完成しているとは言えません。なんとか問題を解決しようと思います。
元々はdynabookにはMicrosoft Windows Vistaが入っていたので、ファイルを同期するのは簡単でした。共有フォルダとして見えるようなっていれば、XCOPY.EXEを利用してファイルをコピーできました。
Vistaがフェーズアウトし、OSをNetBSDに入れ換えたことにより、同期する仕組みを工夫する必要が出てきました。うまい仕組みを作り上げたと思っても、動作が不安定で、なかなか満足のいくものになりませんでした。
そうこうしているうちに、Microsoft Windows 10でWSL（Windows Subsystem for Linux）が利用できるようになりました。WSLを使えば、Windows側のファイルをWSL側から参照することができます。しかも本物のLinuxディストリビューションを利用できるので、U*IX系OSとしてNetBSDとの親和性も高く、同期方式が作りやすくなります。
結局、WSL上でrsyncを使って、ローカルにあるDocumentsフォルダのファイルを、リモートにあるNetBSD上の所定のディレクトリにコピーすることにしました。試しに動かしてみると、上手くいっています。この点では成功と言えるでしょう。
ただし問題もあります。dynabook SS SX/15Aのディスクは60Gしかないので、OSやアプリケーションを入れた後で使える容量は、あまり残っていません。Windows側のDocumentsフォルダにあるものを全てコピーしてしまうと、ディスクが溢れる恐れがあります。そこで余分なファイルはコピーしないようにしたいところです。
このような要望のために、rsyncにはオプション「--exclude」が用意されており、これを使えば解決と言いたいところです。ところが指定方法が難しく、指定してみても、期待した動作をしません（要するに、コピー対象から除外したつもりなのに、コピーされてしまう）。Webを検索しても、うまくいかずに苦労している人達が溢れています。
コピーは出来ているので、ひとまず成功と言えるのですが、コピー除外がうまくいっていないので、完成しているとは言えません。なんとか問題を解決しようと思います。
2019-08-02
PythonにNetworkXをインストール
最長片道切符のグラフ問題を扱うために、PythonにNetworkXを導入してみました。導入するのは簡単ですが、pipを利用します。Python 3.4以降には標準で入っているという情報がありますが、FreeBSDのパッケージで入れたpython 3.6には入っていないようでした。
pipを導入するのは簡単ですが、パーミッションの都合によりrootで操作する必要があります。
グラフ構造を扱うためにNetworkXが必須かというと、そういうわけでもないと思います。しかし重み付きグラフの情報を記したファイルを読み込んでくれるヘルパー関数があるので、自前で似たようなプログラムを書くより楽ではないかと思います。
NetworkXを極めるよりも、最長片道切符のグラフ問題を解くために必要なプログラムを書けるようにするため、NetworkXの使い方を学んでいきたいと思います。
tpe530c> python3.6 -m pip list
/usr/local/bin/python3.6: No module named pip
tpe530c> uname -a
FreeBSD tpe530c 12.0-RELEASE-p8 FreeBSD 12.0-RELEASE-p8 GENERIC amd64
tpe530c> python3.6 -V
Python 3.6.9
furusawa@tpe530c> python3.6
Python 3.6.9 (default, Jul 11 2019, 01:10:39)
[GCC 4.2.1 Compatible FreeBSD Clang 6.0.1 (tags/RELEASE_601/final 335540)] on freebsd12
Type "help", "copyright", "credits" or "license" for more information.
>>>
pipを導入するのは簡単ですが、パーミッションの都合によりrootで操作する必要があります。
# curl -kL https://bootstrap.pypa.io/get-pip.py | python3.6
tpe530c> python3.6 -m pip list
Package Version
---------- -------
decorator 4.4.0
networkx 2.3
pip 19.2.1
setuptools 41.0.1
wheel 0.33.4
グラフ構造を扱うためにNetworkXが必須かというと、そういうわけでもないと思います。しかし重み付きグラフの情報を記したファイルを読み込んでくれるヘルパー関数があるので、自前で似たようなプログラムを書くより楽ではないかと思います。
NetworkXを極めるよりも、最長片道切符のグラフ問題を解くために必要なプログラムを書けるようにするため、NetworkXの使い方を学んでいきたいと思います。
登録:
投稿 (Atom)