■

三連休前の夜に、珍しく zoom 飲み会のようなものに出席した。 zoom ではなく meet だったし、参加者は三名だが接続元は我が家と相手方の二箇所のみというプライベートなものだったが、 WebCam 化した OM-D E-M1 Mark II のバッテリーが切れるまで数時間も話に花が咲いた。楽しかったのでまたやりたい。

三連休は正月にも増してずっと寝ていた。緊急事態宣言が出て外出は控えるべきだから、というよりも単に寒いから。昼食後はすぐに眠くなるし、部屋の中にいてエアコンをつけていても寒いので布団に入って暖をとっているうちに寝てしまう。近年、休日に半分以上寝なかった日が何日あっただろうか、というくらい休日を寝て過ごすのが常態化している。

三日目の夜更け過ぎにようやく重い腰を上げて paperwork に手をつけた。といっても実際は妻にやってもらって、自分はコンビニでコピーをとったり記入済みのドキュメントをメールしたりするだけ。つくづく苦手だ。もう二度とやりたくない、とやるたびに思っていたことを思い出す。

夏用のトレーニングウェアしかないのがジムから足が遠のく言い訳になって久しいのでユニクロのオンラインストアでドライストレッチなんたらいう上下のウェアを注文した。どうせジムの中は空調が効いてるのだから半袖短パンでも大丈夫かと思っていたが、ジムに行くまでが寒すぎる。

■

コロナ以後、自分の生活から隙間時間というものが無くなった。これは自分の精神衛生に悪影響をもたらしていると思う。

仕事が自宅勤務になり、主に通勤時間が無くなったこととダラダラ残業しなくなったことが相まって、可処分時間は増えたはずだが、「使途不明時間」が存在する余地が無くなってしまった。

通勤中の15分。ランチの後の20分。コーヒーを買いにでたついでの5分。そういう細切れの時間に、自分はある種の癒しを感じていたのではないか。

興味深いことに、書くことよりも読むことのほうがダメージを受けているように感じられる。自分にとって書くことの優先度は非常に高く、睡眠時間を削ってでも書かずにはいられない。実際に深夜に書いたりもしているし、そもそも隙間時間では書き切れていなかった（隙間時間に少しずつ書き溜めることもあったが）。

しかし読むことは、特にブログやニュースレターなど、ある程度まとまったボリュームの文章をそれなりに集中して読むのは、テレビをつけたまま SNS のタイムラインを眺めるのと同じ感覚ではできない。 Isolated な時間・空間が必要だ。

結果、 2019 年までと比べても一層読むことが捗らず、読むべき・読みたいものを満足に読めていないストレスを慢性的に感じるようになった。些細なことに腹を立てたり、日常生活にも悪影響が出ている。

■

先月、元上司の退職にあたり、在職者中心に OB/OG にも声かけしてオンライン寄せ書きを作ったらしいことを、久しぶりに Alumni 用の Slack を覗いて知った。そこで呼びかけがあったようだが、頻繁にアクセスしないし通知も切ってるので気づかなかった。 Twitter とか Facebook とかで多少の繋がりはあるのに、誰も教えてくれなかった……。なんたる（おれの）人望の無さよ。おれが書かずに誰が書くのだ？と言いたくなるくらい、書けることはたくさんあったのに。

Linux: プロセスがリダイレクトしているファイルを調べる

正確には file descriptor がどうこう、という話なのだと思うけど、ちゃんと調べる余裕がないのでニーズ起点でメモする。

シナリオ

あるホストのディスク使用量が急増している。あるプロセスが暴走して巨大なゴミデータ（ファイル）を作っていることがわかった。

ディスクを食い潰しているファイルも怪しげなプロセスも特定できているが、果たして本当にそのプロセスが件のファイルを作っている張本人なのだろうか？

プロセスを kill する前に因果関係を特定したい。

解法

あるプロセスがリダイレクトしているファイルは ls -l /proc/$PID/fd で調べられる。 0 = STDIN, 1 = STDOUT, 2 = STDERR

vagrant@vagrant:~$ sleep 600 >/tmp/1.out 2>/tmp/2.out &
[2] 16476
vagrant@vagrant:~$ ls -l /proc/16476/fd
total 0
lrwx------ 1 vagrant vagrant 64 Jan  7 18:23 0 -> /dev/pts/0
l-wx------ 1 vagrant vagrant 64 Jan  7 18:23 1 -> /tmp/1.out
l-wx------ 1 vagrant vagrant 64 Jan  7 18:23 2 -> /tmp/2.out

STDIN が pipe の場合、パイプラインの上流にあるプロセスを特定するには lsof | grep $PIPE_ID を使う。

How can I get more info on open pipes show in /proc in Linux? - Server Fault

vagrant@vagrant:~$ yes | sleep 600 &
[6] 16491
vagrant@vagrant:~$ ls -l /proc/16491/fd
total 0
lr-x------ 1 vagrant vagrant 64 Jan  7 18:25 0 -> 'pipe:[45732]'
lrwx------ 1 vagrant vagrant 64 Jan  7 18:25 1 -> /dev/pts/0
lrwx------ 1 vagrant vagrant 64 Jan  7 18:25 2 -> /dev/pts/0
vagrant@vagrant:~$ lsof | grep 45732
yes       16490             vagrant    1w     FIFO               0,12      0t0      45732 pipe
sleep     16491             vagrant    0r     FIFO               0,12      0t0      45732 pipe
vagrant@vagrant:~$ ls -l /proc/16490/fd
total 0
lrwx------ 1 vagrant vagrant 64 Jan  7 18:25 0 -> /dev/pts/0
l-wx------ 1 vagrant vagrant 64 Jan  7 18:25 1 -> 'pipe:[45732]'
lrwx------ 1 vagrant vagrant 64 Jan  7 18:25 2 -> /dev/pts/0

↑の例だと、 PID 16491 (sleep 600) の STDIN は 'pipe:[45732]' となっていて、この 45732 という数字で lsof の結果を grep すると、 pipe の両端（入力側と出力側）のプロセスの情報が得られる。

片方の PID (16491) は既知なので、もう片方の PID 16490 (yes) が入力側だとわかる。

ls -l /proc/16490/fd の結果は STDOUT が 'pipe:[45732]' となっており、 PID 16491 (sleep 600) の STDIN と一致するので、この二つのプロセスが pipe でつながっていることが確認できる。

真の解法

このトラブルシュートは以下のような流れで行った。

1. ディスク容量が急増していることを検知する
2. 巨大化しているファイルを特定する（du /home など適当にあたりをつけて何度か実行し disk usage の変化をみて絞り込んでいく）
3. top, ps などを利用して怪しいプロセスを発見する（例: cat /dev/random）
4. 怪しいプロセスを kill する

3 と 4 の間に、巨大化しているファイルと怪しいプロセスが関係あるか確認したかった、というのが「解法」のやり方を調べた動機だったが、この手順は良くない。 3 のプロセス特定作業が時間切れになっていたかもしれないからだ。

本来は、以下のような流れでトラブルシュートすべきだった。

1. ディスク容量が急増していることを検知する
2. 巨大化しているファイルを特定する
3. lsof で件のファイルに書き込んでいるプロセスを特定する
4. そのプロセスを kill する

これなら最短で問題のプロセスを特定できる。大量のプロセス一覧から怪しいプロセスを探す必要はない。

vagrant@vagrant:~$ perl -E 'while(true){ say 0; sleep 0.1}' >/tmp/0.txt &
[1] 16536
vagrant@vagrant:~$ perl -E 'while(true){ say 0; sleep 0.1}' >/tmp/0.txt &
[2] 16537
vagrant@vagrant:~$ lsof /tmp/0.txt
COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
perl    16536 vagrant    1w   REG  253,0    49152 3801099 /tmp/0.txt
perl    16537 vagrant    1w   REG  253,0    49152 3801099 /tmp/0.txt
vagrant@vagrant:~$ ps 16536 16537
  PID TTY      STAT   TIME COMMAND
16536 pts/0    S      0:01 perl -E while(true){ say 0; sleep 0.1}
16537 pts/0    S      0:01 perl -E while(true){ say 0; sleep 0.1}
vagrant@vagrant:~$ kill 16536 16537
vagrant@vagrant:~$
[1]-  Terminated              perl -E 'while(true){ say 0; sleep 0.1}' > /tmp/0.txt
[2]+  Terminated              perl -E 'while(true){ say 0; sleep 0.1}' > /tmp/0.txt

2 のファイル特定作業も手間取って時間切れになっていたかもしれない。もっと良い方法を知りたい。

2020-01-12 追記

linux ファイル容量降順にソート - Qiita

du -a オプションをつけるとディレクトリだけでなくファイルも表示される（ディレクトリも含まれる）。

du -a | sort -rn | head
du -ak | sort -rn | head  # KB単位
du -am | sort -rn | head  # MB単位
du -ag | sort -rn | head  # GB単位
du -ah  # 単位をいい感じに表示してくれるが sort しづらい

ファイルだけにしたい場合は find を使う。

find - Getting size with du of files only - Unix & Linux Stack Exchange

find . -type f -exec du -a {} + | sort -rn | head

■

Instagram、何年もアプリをほとんど開きもしなかったくらい使ってなかったので、まれに開くと難しすぎて使い方がわからない。なんか下の真ん中にある動画っぽいアイコンを押したらいきなり大音量で音が鳴ったりして、うかつに押すのもこわい。ストーリーズってやつが最初なのか、何枚かの写真が数秒ごとに切り替わっていってプログレスバーが出てるやつ、あの UI がかろうじて操作できるレベル。

インターネット大好きどころか2ちゃんねらーからはてな村民へと順調にステップアップ（ダウン）してたくらいネットに浸かっていた人間だったはずなのに、この体たらくはなんたることか。でも、おかげで親世代の老人とか、いわゆるITリテラシーの低い人たちがどう感じるか、を疑似体験できたようなものなので、悲観することばかりでもない。これは頭ごなしに「こんなこともわからないの？できないの？」と言われたら抵抗あるだろう。