Windows10 crash
前回の枕にHDDの安全な処分方法をプチ検討した。塩水漬けやらトイレ用塩素系漂白剤漬けとか、叩き壊すやら。
でふと思った。HDDを車載してるよね。随分昔の車（長く乗り過ぎると自動車税が上がるって言う、メーカーと結託した税制に悩まされる年頃）だけど、CDが何百枚も仕舞えるって言うからHDDだよね。そんな耐衝撃性が有るのか？
ショッキングオレンジの箱なのに、ブラックボックスとはこれいかに？ こちらは、その耐性が極度に求められるはず。そんな所にHDD使ってるのかなあ？
航空機の「ブラックボックス」は事故の原因をどうやって解明するのか？
どうやらHDDではなくて、テープレコーダーなのね。そういうばそうだわ。HDDのヘッドって空気で浮くんだから、そんなHDDは原理的に使えないな。
破壊性の所に、航空機燃料やら、トイレ用洗浄液に48時間漬けるなんて項目が有る、妥当な試験だと思うよ。
ボイスレコーダーのピックアップ感度を上げるのにパイロット組合が猛反対したとか。酒酔いパイロットは特に反対したいよね（こらこら）。
そのうち、車の全車両がブラックボックス搭載を義務付けされるよね。警察、保険会社、大賛成。
やや、中東の航空機墜落現場から、ブラックボックスが回収されたなんて報道してるなあ。噂の国はこれに観念したのが、誤爆を発表したな。
Qubes OS
某OSをdisっていたら、
QUBES OSなんてのを紹介された。NSAに盾ついたあのスノーデン氏も使っていると言うやつ。
山形浩生さんも試してる。Qubes OS 4.0 を Lenovo Thinkpad X250 にインストールしてみた
豪華にメモリーを積んでいないとまずいらしいので、しょぼくれたvboxだと、版を落とす必要があるみたい。VirtualBoxに匿名性OS「Qubes OS」をインストールする方法
/etc/rc
OpenBSDいいよの投稿の追加です。 OS起動時にカーネルがちゃんと動くようにし、最後の仕上げとしてユーザー側の環境の整備が行われる。その肝となるのが、/etc/rcと言うshellスクリプトだ。
このスクリプトから、DISKの不整合チェックやらマウント実行、NICの準備とか、ダエモン君を起こして、裏仕事を任せるとかの実行が行われる。そして、最後にユーザーがログイン出来るように、受付プログラムを起動。全部で600行ぐらいのやつだった。
このファイルを変更すれば、どうでもなるんだけど、そういう荒っぽいかつ危険な事は避けるようになっている。例えば、このダエモン君は要らないから起動不要とか、リモートログインしたいんで、sshdを起動しといてとか、GUIから使いたいんで、GUIの準備をしといて、等々。
カスタマイズ出来るようになってる。デフォルトの設定ファイルは、/etc/rc.conf 実に分かり易い仕様。どこかのsystemdみたいな、難解な事は一切無し。
デフォルトでは、サーバー向けのダエモン君が起動するように調整されている。しかしオイラーみたいに、開発っぽい事をやる人には不要な物を起動してる。じゃ、それを止めるのにrc.confを変更すればいいじゃんってなる。
確かにそれでいいんだけど、Teo親分は、rc.confとの差分をrc.conf.localに書けって推奨してる。根幹を変更してわけわかめにされるより、よっぽど管理が楽になる。おかしな動作って疑う時は、単にrc.conf.localを（必要ならBackupの上）削除するだけで、初期状態に戻せるからね。
オイラーのローカルは、下記の様
o32$ cat /etc/rc.conf.local smtpd_flags="NO" ntpd_flags="NO" slaacd_flags="NO"
メールなんてしないから、時刻合わせで安定する頃にはシステムをshutdownしちゃうから。ああ、この時刻合わせのダエモン君は、OpenBSDのユーザーだけが使える、特製安全プログラムだ。 まだ、doasみたいに普及していないだろうね。slaacdはIPv6関連なので、迷わずに止めている。
余計なプログラムは動かすなってのが、鉄則だからね。その逆を行くのが何とかDesktopって奴。まあ、必要だから動かしているんだろうけど、中には起動後一度も使う事が無いやつも動いているぞ。資源の無駄使いでセキュリティの穴を拡げているようなものだ。
細かい事は、man rc すると出てくる、関係者を当たれば良いだろう。
FILES
/etc/netstart Command script for network startup.
/etc/rc Command scripts for system startup.
/etc/rc.conf System daemon configuration database.
/etc/rc.conf.local Site specific daemon configuration database.
/etc/rc.d Directory to hold rc.d(8) scripts.
/etc/rc.d/rc.subr Functions used by the rc.d(8) scripts.
/etc/rc.firsttime Commands run on the first boot after creation.
/etc/rc.local Site specific command scripts for system startup.
/etc/rc.securelevel Commands run before the security level changes.
/etc/rc.shutdown Commands run at system shutdown.
/fastboot Tells rc not to run fsck(8) during the next boot.
/var/run/dmesg.boot Copy of dmesg(8) saved by rc at boot time.
qemu
余り熱くなるのも、あれなんで、話題を移す。久しぶりにqemuで仮想マシンでも立ち上げようかねぇ。qemuで動くOpenBSD6.6がdebianに作ってあるぞ。なら、それを持ってきて手抜きするか。インストールの手順が省けるからね。ってんで、qemuの起動スクリプトも持ってきた。
o32$ cat boot ulimit -c 0 #qemu-system-i386 -m 128 -nographic disk #qemu-system-i386 -m 256 -nographic -net nic -net user,hostfwd=tcp::2022-:22 disk & #qemu-system-i386 -m 256 -net nic -net user,hostfwd=tcp::2022-:22 disk -S -gdb tcp::1234 qemu-system-i386 -m 256 -net nic -net user,hostfwd=tcp::2022-:22 disk
色々なラインがあるんで、使い分けろだな。まあ、デフォでX11上にコンソールが出てくるやつでも試してみるか。
o32$ ./boot qemu-system-i386: cannot set up guest memory 'pc.ram': Cannot allocate memory
やや、早速トラブル。メモリー不足って言われてもねぇ。この環境は上で出て来た、Qubes OSじゃないですよ。
Windows10 crash
ここで、臨時ニュースを申し上げます。この原稿を書いているWindows10上のemacsが固まりました。
漢字変換しようとしたら、応答が無くなりました。何分待っても復帰せず。しょうがないので、涙を呑んで、emacsを殺そうとしたら、emacs画面が白濁。
横で動いていたfirefoxも止めようとしたら、やはり画面が白濁。同時に動かしていたVMwareも白濁。もう、全面的に、Windows10がクラッシュです。
最終手段の電源ボタンを長押し。
それにしても、たかがemacsとIMEとのやり取りでWindows10全体が壊滅的に動かなくなるって、どうよ。firefoxとか他のアプリまで制御不能に陥らせるなんて、それでもお前OSか。よそのアプリを白濁させる余裕なんて、どうでもいい事よ。真面目にやれ。
そう言えば、最近はIMEの早とちり症候群（指示してないのに勝手に確定する変な病気）の症状が出ていないな。完治したんだか怪しいものだ。
復旧作業
煙が収まった頃を見測って、Windowsを再起動。特にクラッシュしましたとかの報告もなく、普通に起動した。
書きかけの原稿（勿論saveなんてしていない）が、取り戻せるか？ はらはらドキドキしながら 該当ファイルを読み込ませると、 recover-this-file って聞いてきた。勿論、おねげーしますだ。emacs先生。
原稿を確認すると、最後の一行だけを紛失しただけで、それ以前の行は全部復旧した。 ときたま、Auto saving ... って、出てたけど、これが役にたったのね。感謝ですよ。
これが、Windows上の糞アプリだと、１日分の仕事をパーにした、なんて嘆き節をよく聞くんで、emacsの作りには感心しますよ。
firefoxはどうかな？ クラッシュしたんでリカバリーしますとか言って、開いていたページを 再読み込みするはずなんだけど。。。 今回は、そうならなかった。プライベートモードで使っていたんで、綺麗さっぱり昔の事は忘れているんだろうね。
それから、起動してたOpenBSDは起動時に、fsckが走ってた。そして無事に起動。実害と言えば、lastコマンドで出てくる履歴に、クラッシュ前のログインがされっぱなしって記録されてただけだった。
尤も、コンパイル等のDISKに負担をかける（書き込みね）作業は、極力RAMDISKにしてる /tmp の下でやるようにしてる。/tmpは、オイラー的には捨て鉢な場所と心得ているから、どうなっても良い。どうせ、rebootすれば、綺麗さっぱりクリアされますから。
こういう行動って、どこかQubes OS的な使い方をしてるって事だね。
emacs auto save
Emacsでファイルの自動保存 (auto-save-buffers)
少々古い記事だけど、今でも通用するのかな？ オイラーはemacsを多用してるけど、自動保存に注力した事は無い。
300文字/30秒ってのは、昔から変わらないやつなのね。
Emacsは、致命的なエラーが発生したときも自動保存を行います。 これには‘kill %emacs’のようなコマンドによるEmacsジョブのkill、 電話回線やネットワーク回線の切断が含まれます。
こういう事が書かれていると、ついやってみたくなる。
/etc/rc を捨て鉢にrc.txtって名前でコピー。最終行に追加。但し保存はしない。 この状態で、kill emacsを実行。
ob$ diff -u rc.txt \#rc.txt\# --- rc.txt Sat Jan 11 07:00:49 2020 +++ #rc.txt# Sat Jan 11 07:04:30 2020 @@ -620,3 +620,5 @@ date exit 0 + +add by sakae
ちゃんと保存してるね。じゃ、普通に emacs rc.txt すると
rc.txt has auto save data; consider M-x recover-this-file
こんな案内が出てきた。recoverしない限り、更新前の状態。recoverする（更新後の状態）なら、指示通りのコマンドを叩けばよい。
Recover auto save file /tmp/#rc.txt#? (yes or no) yes
利カバーした状態で、終了しようとすると、こんな質問が出る。
Save file /tmp/rc.txt? (y, n, !, ., q, C-r, d or C-h)
emacs的には、ファイルが更新されてるので、どうするか問うているんだな。saveした後も（しなくても）#rc.txt#は残ったままの状態なので、不要なら消せばよい。
じゃ、emacsを即死させたらどうなる？ kill -9 emacs ね。勿論、バックアップを作る余裕が無いので、更新ファイルは作成されない。まあ、当たり前だな。
300文字かつ30秒を越えていれば、シャープファイルに最新内容が書き込まれている。もしもの時の保険になるぞ。ってか、もしもに備えるのが保険だろうに。
ガン保険に入ってるのにガンにならないなんて、何となく損した気分 なんて言うなよ。＞女房。
kill xxx vs. kill -9 xxx
xxxは、pidの指定。いちいちpidを調べてからkillするのが面倒なら、killの代わりにpkillを使えば、名前で指定出来る。（複数の名前が見つかった場合、全てが対象になる）
killにシグナル名を明示しない場合、sigtermを指定したものと見做される。
9 KILL (non-catchable, non-ignorable kill)
15 TERM (software termination signal)
9番は、ゴルゴ13みたいなやつ。問答無用でプロセスを殺してくれる。それに対して15番の方は落語に出て来るような優しい死神、終活を許してくれる奴ね。editorの終活って言えば、まだ保存してないファイルを保存するって事。但し遺産としてね。（上のemacsの例で言えば、シャープで囲まれたファイル）
遺産は、特別扱いをしなさいって、世の中の道理を受け継いでいる。だから、特別な利用手続きが必要になるのさ。
OpenBSDのviでは、どうよ？
再び、rc.txtを題材にする。vi rc.txt して、ファイルを開いた。（編集は何もしていない） 別端末か、ら pkill vi してみたよ。
その時の挙動は
ob$ vi rc.txt Terminated
viにSIGTERMが送られて、viはTerminatedされましたと言われた。報告出来る余裕が有ったのだな。
ob$ ls vi.recover/
vi.WTrq550H9R*
ff -u rc.txt vi.recover/vi.WTrq550H9R <
Binary files rc.txt and vi.recover/vi.WTrq550H9R differ
ob$ ls -l vi.recover/vi.WTrq550H9R
-rwx------ 1 sakae wheel 22528 Jan 11 15:32 vi.recover/vi.WTrq550H9R*
ob$ wc rc.txt
622 2384 15871 rc.txt
/tmpの下には、あらかじめvi.recoverってdirが用意されている。普段は空だけど、今回は中身が有った。んで、多分textファイルだろうと思ったら、想像を超えてバイナリーファイルだった。元ファイルとも大分違うようだ。
気を取り直して、vi rc.txt してる時に、vi.recoverを見たら、ファイルが作成されてた。viを普通に終了すれば、そのファイルは消える。作業領域って事なんだな。
viで開いているrc.txtに変更（追加）してると
ob$ ls -l vi.recover/ total 54 -rw------- 1 sakae wheel 462 Jan 11 15:59 recover.7fCWOYEi38 -rw------- 1 sakae wheel 26624 Jan 11 15:59 vi.j6qkPvhjVq
作業エリアに変化が表れた。この状態でpkillする。はて、どうやって利カバーする？ そりゃ、やっぱりmanを精査しなさいだな。
-r Recover the specified files or, if no files are specified, list
the files that could be recovered. If no recoverable files by
the specified name exist, the file is edited as if the -r
option had not been specified.
SIGTERM If the current buffer has changed since it was last written in
its entirety, the editor attempts to save the modified file so
it can be later recovered. See the vi/ex reference manual
section Recovery for more information.
関連と思われるやつを、抜き出してみた。そして、
ob$ vi -r Sat Jan 11 15:59:57 2020: rc.txt
利カバー対象を教えてくれるのね。後は vi -r rc.txt で良いはず。なんだけど、追加更新したものが出てこない。
細かい事はリファレンスマニュアルに当たれとな。/usr/src/usr.bin/vi/doc/USD.doc/の中に、vi.refとかが有った。多分この事だろう。manの原稿ぽいのとMakefileが用意されてた。 makeって叩くとマニュアルが作成されるのかな？
やってみたら、bsd.doc.mkが無いと言って怒られた。しょうがないので、Makefileを開いてみると、核心は
paper.txt: vi.ref index.so
soelim vi.ref | ${TBL} | ${ROFF} -U -Tascii > ${.TARGET}
ふーん、soelimってコマンドが必要なのか。そんなコマンドも見当たらない。歴史的な文書だから、復元用ツールは用意してないのかな。このMakefileも2004年製だし。
諦めて、別の手を考える。対象はmanの原稿なんで、man man したよ。そしたらmandocを紹介されたよ。
ob$ mandoc -T ascii ./vi.ref | less
で、読みにくいやつが、普通のテキストになってくれた。ちょっと読みにくいけど、まあ、古墳から出て来た文書を解読する積りで、
superuser may recover any edit session. Edit sessions are backed
by files in the directory named by the recdir option (the
directory /tmp/vi.recover by default), and are named
"vi.XXXXXXXXXX", where "XXXXXXXXXX" is a number related to the
process ID. When a file is first modified, a second recovery
file containing an email message for the user is created, and is
named "recover.XXXXXXXXXX", where, again, "XXXXXXXXXX" is
associated with the process ID. Both files are removed at the
end of a normal edit session, but will remain if the edit session
is abnormally terminated or the user runs the ex preserve
:
the shell script /etc/rc executes the vi recovery script
/usr/libexec/vi.recover. This takes care of removing stale
そうか、メールでお知らせか。recover.xxxがその文面ね。
ob$ cat vi.recover/recover.rxXgIdwMBI
X-vi-recover-file: rc.txt
X-vi-recover-path: /tmp/vi.recover/vi.TOKTrFO1dQ
Reply-To: root
From: root (Nvi recovery program)
To: sakae
Subject: Nvi saved the file rc.txt
Precedence: bulk
Auto-Submitted: auto-generated
On Sun Jan 12 07:49:03 2020, the user sakae was editing a
file named rc.txt on the machine ob.localdomain, when it was
saved for recovery. You can recover most, if not all, of the
changes to this file using the -r option to vi:
vi -r rc.txt
(日を改めたのでxxxの部分は異なる) この文面を見ると、リカバリーの方法は間違っていないね。
で、結論的には、viで開いて、修正して書き込んで、（続けて修正してもいいけど）ほっておいた時に、不慮の事故に遭った場合、リカバーされるのは、書き込んだ所までって事だ。 なんだかなあって、思うぞ。それとも、オイラーが誤解してる？
みんな大好きなやつは、どうかな
OpenBSDと同じ実験。開いたファイル（のバッファに追加）更新し、書き込まないでおく。 そして、優しい死神を遣わす。
(base) sakae@debian:test$ vi aa.txt Vim: Caught deadly signal TERM Vim: preserving files... Vim: Finished. Terminated
死神が来たんで、遺産を残して死にました。次は、遺産の回収モードで起動。
(base) sakae@debian:test$ vi -r aa.txt : Using swap file ".aa.txt.swp" Original file "~/test/aa.txt" Recovery completed. You should check if everything is OK. (You might want to write out this file under another name and run diff with the original file to check for changes) You may want to delete the .swp file now.
ちゃんと案内が出て来た。心配なら別ファイル名で保存して、ちょろまかしが無いか、確認してね。 後は、.aa.txt.swpを消しておけばいいんだな。さすが、鍛えられているな。
再びOpenBSDのviに戻って、SIGTERMを受けた時にどんな挙動になるか、追ってみたい。結論を先に書くと、迷路に迷ってしまい、目的地に到達ならず。
SIGTERMって割り込みでしょ。そのあたりを追えばいいんでないかい。ええ、
./cl/cl.h:#define CL_SIGTERM 0x0080 /* SIGTERM arrived. */ ./cl/cl_main.c: F_SET(clp, CL_SIGTERM); ./cl/cl_main.c: clp->killersig = SIGTERM;
clってdirは、配置情報によれば、Source files for nvi's curses screen support. だそうです。画面制御の中にmainが有りました。ここで、SIGTERMとかのハンドラ制御を一括コントロールしてるみたい。いわゆるeditorの本体は、ここから呼び出される構造。 既に、このあたりから迷い道に踏み出したみたい。
common/key.c
switch (argp->e_event) {
case E_ERR:
case E_SIGHUP:
case E_SIGTERM:
/*
* Fatal conditions cause the file to be synced to
* disk immediately.
*/
v_sync(sp, RCV_ENDSESSION | RCV_PRESERVE |
(argp->e_event == E_SIGTERM ? 0: RCV_EMAIL));
return (1);
v_syncの中で、rcv_syncが呼ばれる。 common/recover.c
/* * rcv_sync -- * Sync the file, optionally: * flagging the backup file to be preserved * snapshotting the backup file and send email to the user * sending email to the user if the file was modified * ending the file session
多分、ここなんだろうね。冒頭に
* Recovery code. * * The basic scheme is as follows. In the EXF structure, we maintain full * paths of a b+tree file and a mail recovery file. The former is the file * used as backing store by the DB package. The latter is the file that * contains an email message to be sent to the user if we crash. The two * simple states of recovery are: * * + first starting the edit session: * the b+tree file exists and is mode 700, the mail recovery * file doesn't exist. * + after the file has been modified: * the b+tree file exists and is mode 600, the mail recovery * file exists, and is exclusively locked.
メールで知らせてあげるのに、ご熱心。昔は、遠隔から音響カプラー経由のモデムとかで繋いで、オペレーションする事が多かったんだろうね。で、予期せぬ事情で、接続が切れる。 そんな時は、次回のログイン時に、復旧方法を教えてあげる。
b+treeってファイルは、変更分を記録してるのかな。リカバーする時は、オリジナルなファイルと合成して、反映させる。こんな方針で動いてるやつがいたな。そう、みんな大好きなMySQLみたいなデータベースシステム。
これを確認するんだったら、-r オプションの挙動を調べればいいのか。まて、その前にブラックボックステストをやってみろ。実験計画は次の通り
ob$ vi Makefile ;; ぐちゃぐちゃ追加変更、save Terminated ;; 突然、死神が枕に立った ob$ rm Makefile ;; 元ファイル削除 ob$ vi -r ;; 遺産確認 Sun Jan 12 15:43:35 2020: Makefile ob$ vi -r Makefile ;; みんなで山分け
変更されたファイルって言ってきたけど、中身が欠けてる。もう少しちゃんと調べろよ。例えば、diffが取れるように、オリジナルを残しておくとか。お前は、研究者落第だな。
話題を逸らして、難を逃れるのが処世術。
viにcursesが使われていた。emacsの代替のlemでも使われていた。ならば、きっと本場のemacsにも使われているだろう。ビンゴでした。良い勘してるね。
cursesって画面制御でしょ。昔FM-11ってパソコンを使っていたのよ。こやつが生意気にメインCPUと画面制御用のCPUを積んでいた。メイン側からは、裏で動くCPUにどんな事をやらせたいか、コマンドブロックってのを組み立てて、コマンドを発する。
そうすると、画面の上をカーソルが飛び回ったり、色を付けたり、特定の行とかをイレーズ出来た。若かったので、これを利用して、自前のスクリーンエディタを作ったな。良い思い出だ。
今なら、同じ事をcursesを使って出来るんだね。昔を思い出してやってみるか。