2022年02月のまとめ。

• Laptop
• ピスタチオ
• Octoprint高負荷
• メインPCのディスクあふれ
• denite.vim
• Xorgのログ
• Wemo plugの監視
• 家計簿

2月

• 1
  • Laptop
    • キーボード基板を印刷してみた。
    • 試すのはまた明日
• 6
  • ピスタチオ入れ
    • blenderの練習がてら書いてみた
    • サブディビジョンサーフェスっていうのが重要な機能みたい。
• 7
  • ピスタチオ入れ
    • 印刷してみた。
      • 底が抜けた。
    • 印刷中に止まる
      • CPU使用率が高い
      • 低電圧アラートがでてる。
        • このコードからアラートがでてる。
        • vcgencmd get_throttled 1でアラートを解除できる。
        • しかし、解除するとすぐアラートがでる。
        • 電圧計を付けよう。
• 8
  • Octoprint
    • 先日の印刷中の高負荷が気になる。
    • 予想は
      • vaseモードはcommand per secが結構多いのでそのせいの可能性
      • 使ってるプラグイン(例えばDashboard plugin)は、gcodeをほげほげしてるので遅い可能性 https://github.com/j7126/OctoPrint-Dashboard/blob/a1a6e88db63b5033e57b086dd030a82f7fcd496b/octoprint_dashboard/init.py#L721
      • Raspi4は4コアなのに、Pythonのせいか、Octoprintのせいか1コアしか使ってない
      • blenderの出すstl(特にサブディビジョンサーフェスを使ってるやつ)はcuraに向いてない可能性
      • 電力不足でアレな可能性
  • メインPCのディスクあふれ
    • 論文の再現手順で再現できるかチェックして欲しいと頼まれた。
      • 試したら、ディスクがあふれた。
      • 容量が残り少なくなってたみたい。
    • とりあえず、使ってなくて容量が多そうなWineを消してapt autoremoveしたら5%ぐらいはあいた。
    • 写真のバックアップを消した。
      • btrfsのスナップショットからも消せた。
      • sudo btrfs property set -ts /path/to/snapshot ro false
      • 終わったら
      • sudo btrfs property set -ts /path/to/snapshot ro true
      • これで10%ぐらいあいた。
• 9
  • Pythonのプロファイラ
    • サンプリングプロファイラが欲しい
    • いろいろあるけど、py-spyというのを試そうと思った
    • インストールでつまずく
      • pip install py-spyで入らなかった。
      • apt install cargoしてcargo install py-spyでもエラー
        • これだからRustは
      • rustup.rsから入れたらできた。
    • 試すのは明日だな
• 10
  • Octoprintの高負荷
    • 今ためしたらおきない。
    • 一応py-spyを実行してみたけど、怪しいのは見付からず。
• 11
  • denite.nvim
    • 本体は去年インストールしたけど、いつのまにか動かなくなってた。
    • 調べたら、deniteが使うpythonにpynvimが入ってなかった。
      • たぶん、アドホックにその時使ってたマシンにだけ入れたんだろう。
    • mitamaeの設定ファイルにpython3-pipとpip install pynvimを追加した。
• 12
  • ArduinoISPとArduinoのリセット
    • 調べたら面白かったので、blogに書いた。
  • Xorg
    • この間のディスクあふれのもう一つの問題がXorg.n.logが10GBぐらい使ってる事。
      • こんなのが毎秒100行ぐらい書かれてる。
        • [1745030.172] (II) AMDGPU(0): Modeline "1024x600"x0.0 50.25 1024 1068 1156 1344 600 603 609 625 +hsync -vsync (37.4 kHz eP)
      • 去年一度問題になり、スナップショット範囲外に取りだした
        • スナップショット範囲外だから再起動ごとに倍に増えたりしないが、地味に増える。
    • 調べたら、journaldのログにも同じ情報が出てた。
    • AMDGPUは内蔵グラフィックのモジュール
      • ケーブルがアレで何かリセットがされて出てる？
      • AMDGPUはプロプラのモジュールを入れているので、それが腐ってる？

    • ps aux

      grep Xorgしたら、-verbose 3というオプションが設定されてる。

      • これを-verbose 0にしたら解決する？
      • どこで設定されてる？
        • pstreeによると親プロセスはgdm-x-session

          ├─gdm3─┬─gdm-session-wor─┬─gdm-x-session─┬─Xorg───24*[{Xorg}]
          │      │                 │               ├─xmonad-x86_64-l─┬─3*[sh───vim───2*[{vim}]]
          │      │                 │               │                 └─ssh-agent
          │      │                 │               └─2*[{gdm-x-session}]
          │      │                 └─2*[{gdm-session-wor}]
          │      └─2*[{gdm3}]
          

          • /etc/gdm3の下にそれっぽい設定ファイルはない。
            • /etc全体を見てもそれっぽいのがない。
          • strings /usr/lib/gdm3/gdm-x-sessionをしてみた。

            none
            -noreset
            -keeptty
            -verbose
            -core
            could not start X server: %s
            

            • 設定ないのかよ。
            • objdump -s /usr/lib/gdm3/gdm-x-session | grep -A 10 -B 10 verbose

               116e0 4749432d 434f4f4b 49452d31 0052756e  GIC-COOKIE-1.Run
               116f0 6e696e67 20582073 65727665 7200636f  ning X server.co
               11700 756c6420 6e6f7420 6f70656e 20706970  uld not open pip
               11710 653a2025 7300584f 52475f52 554e5f41  e: %s.XORG_RUN_A
               11720 535f5553 45525f4f 4b005844 475f5654  S_USER_OK.XDG_VT
               11730 4e520076 74256400 2f757372 2f62696e  NR.vt%d./usr/bin
               11740 2f586f72 67002d64 6973706c 61796664  /Xorg.-displayfd
               11750 002d6175 7468002d 6c697374 656e0074  .-auth.-listen.t
               11760 6370002d 6261636b 67726f75 6e64006e  cp.-background.n
               11770 6f6e6500 2d6e6f72 65736574 002d6b65  one.-noreset.-ke
               11780 65707474 79002d76 6572626f 73650037  eptty.-verbose.7
               11790 0033002d 636f7265 00636f75 6c64206e  .3.-core.could n
               117a0 6f742073 74617274 20582073 65727665  ot start X serve
               117b0 723a2025 73003a25 7300556e 61626c65  r: %s.:%s.Unable
               117c0 20746f20 72756e20 58207365 72766572   to run X server
               117d0 0a005275 6e6e696e 67207365 7373696f  ..Running sessio
               117e0 6e206d65 73736167 65206275 73006462  n message bus.db
               117f0 75732d64 61656d6f 6e002d2d 7072696e  us-daemon.--prin
               11800 742d6164 64726573 73002d2d 73657373  t-address.--sess
               11810 696f6e00 28737329 00476574 002f6f72  ion.(ss).Get./or
               11820 672f6672 65656465 736b746f 702f7379  g/freedesktop/sy
              

              • この”3”(0x33)を”0”(0x30)に書き換えればいいのかな？
      • バイナリエディタでここを0にしてみた。
        • journaldには吐かれなくなった。
        • Xorg.n.logには出つづけてる。
        • たぶん、-verboseに追加で-logverboseも設定しないと駄目そう。
    • ソースを探したら出てきた。
      • https://github.com/GNOME/gdm/blob/main/daemon/gdm-x-session.c#L282
        • やっぱり直書きか。
    • ソースから変えよう。
      • dpkg -S /usr/lib/gdm3/gdm-x-session
      • apt source gdm3
      • cd gdm3-3.36.3
      • ソースを書き換え ``` @@ -282,9 +282,12 @@ if (state->debug_enabled) { g_ptr_array_add (arguments, “7”); } else {
        • g_ptr_array_add (arguments, “3”);

        • g_ptr_array_add (arguments, “0”); }

        • g_ptr_array_add (arguments, “-logverbose”);
        • g_ptr_array_add (arguments, “0”); + if (state->debug_enabled) { g_ptr_array_add (arguments, “-core”); } ```
      • dpkg-buildpackage -b -uc
      • cd ..
      • sudo dpkg -i gdm3_3.36.3-0ubuntu0.20.04.4_amd64.deb
      • これで、Xorg.n.logからも、journaldからもAMDGPUのログが消えた。
      • これ元パッケージがバージョンアップすると壊れそう。どうするべきかは要調査
    • Xorg.n.logは単純に削除、journaldはjournalctl --vaccum-time=1h
• 13
  • blog更新
    • 先月分のメモ
  • Wemo plugを監視
    • 部屋の電気を付けたり消したりをこれでやってる。
    • たまに操作できなくなる。
    • しかし、Web UIなどはない。
    • prometheusでpingで監視してみる。
    • これで有効か様子見。
• 14
  • deniteを使った時、vimとpythonがCPUをくいつぶすのが見えた。
    • とりあえず、件数を1000件までにしぼってみる。
• 16
  • denite.nvimの暴走
    • 気がついたら、VimとpythonのプロセスがCPUを使い切ってた。
    • 最近メインで使いはじめたし、vimとpythonといえば、denite.vimがわるそう。
    • たまに暴走するみたい。
    • python側straceを見るとdenite用の通信だけをしてる。
    • ゆっくり操作したら回避できそう。
    • しかし、高速作業するからdenite.vimを入れたんだが。
• 18
  • 3mkのチャタ
    • なんかここ数日チャタるようになってて、原因を探してた。
    • 良くみたら、ハンダ不良だった。
    • なおったかな。
  • HBKC
    • それなりに人がいた。
  • mon-shin にきた質問
    • なんかいじってたら、キーボードがマスストレージデバイスになったという質問
    • そんな馬鹿なと思ってたら、そういうブートローダーがあるらしい。
      • https://scrapbox.io/self-made-kbds-ja/LUFA_MassStorage_Bootloader
    • ただ、Linuxではうまく書けないみたい。残念
• 19
  • denite.nvim
    • 先週困ったdeniteが暴走する件
    • とりあえず、ミニマルな再現方法を探す。
      • あと、デスクトップPCでも再現する方法を探す。
      • 10秒かけて1000行の候補を出すシェルスクリプトを書いてみた。
        • これだけをsourceにして数回試したら再現する。
      • py-spyをかけてみる。
        • msgpackまわりがCPUを使ってる。
        • しかし、これが異常なのかもわからん。
    • githubのissueレポートしてみる。
      • NVIM_PYTHON_LOG_FILEを設定するとログを吐くらしい。
      • ログを見ると、_denite_do_mapというRPCをVimがPythonに数ms間隔で送り続けているようだ。
    • 返事1
      • 返事がきたけど、どうも、パフォーマンスが悪いと文句を言ってると取られたみたい。
      • Vim-jpのslackでつかまえて説明してみる。
      • レポートに、パフォーマンス問題じゃないと書いておくべきだった。
    • 返事2
      • 10msおきに候補を出すために、標準のposix sleepコマンドでは10ms待ちできないので、 sleepenhを使っていたが、これがポータブルでないという問題で、再現してもらえなかった。
        • posixではread -t 0.1とかするのが定石らしいけど、標準入力がないsourceでは使えない。
      • 最終的にシェルスクリプトをやめてPythonで再現sourceコードを書き直した。
    • 返事3
      • 修正してもらえた。
        • 素晴しい。
        • https://github.com/Shougo/denite.nvim/commit/fbee9c1d2ff6d58b6b24c079fbb221414857cb9e
          • これ見ても何がどうなってるのかわからん。
    • 敗因
      • Vimで定期実行をどうやってるのか知らなかった。
        • 昔はCursorHoldで頑張ってた記憶がある。
        • vim8からtimer_start関数というのが作られてそれを使ってるらしい。
      • Vim scriptデバッグ力が足りない。
      • Vim-jpのslackでは、CtrlPプラグインの方がポータブルで良いよという意見ももらった。
        • denite.nvimで解決できない問題があったらこれでいこう。
        • ただ、例えば、qmk_firmwareは5万ファイルぐらいあるから、uniteでもCtrlPでも厳しそう。
          • https://zenn.dev/mattn/articles/a2f962733fad2f8613d1 いや、36,000ファイルでもいけるとある。
            • どちらかというと、自分の場合遅いファイルシステムを使ってる時が問題なのかも。
      • そもそも、こういう非同期プロセス難しいよね。
        • 自分ならどういう設計するかな？
        • 効率を下げてでも双方向にRPCを呼ばないアーキテクチャにできるだろうか？
• 22
  • 家計簿
    • Zaimもマネーフォワードもスクレイパーがまともに動作しないから、自前で持ちたい。
    • とりあえず、GnuCashを使おうと思う。
    • とりあえず家計を出してる新生銀行と、三井住友のクレジットカードのデータを取り出してみる。
      • どちらも、CSVで出せる。
      • 直接GnuCashで、CSVを読ませようと思ったが、正規化されてなくてうまくできない。
      • RubyとCSVとQIFでQIFに変換するスクリプトを書いた。
• 23
  • 家計簿
    • 銀行、クレカの仕訳は手作業でやった。
    • 向きが間違ってた。
      • クレカのCSVは買った物の値段が書いてあり、これをそのままQIFに入れていた。
      • しかし、クレカからお金を出しているから、マイナスとして書くべきだった。
    • ついでにAmazonの購入履歴を入れてみる。
      • CSV出力がないが、それをやる拡張機能を見つけた。
        • アマゾン注文履歴フィルタ
        • ただ、人によっては動かないらしい、来年やるとするとスクレーパーを自作しないと駄目かも。
      • 昨日と同じ要領でQIFにした。
      • Payee欄を商品名にしたが、商品1つ1つ仕訳しなくてはらなず辛い。
        • ASINからカテゴリ名を取りだして入れるべきか？
• 25
  • Webサーバーのディスク容量警告
    • 90%を越えたって言われた。
    • とりあえず、ログを消したら3Gぐらいはあいた。
      • sudo sh -c "truncate -s 0 /var/lib/docker/containers/*/*-json.log"
    • あと、postgresqlがでかい。全体の半分を使ってる。
    • Repackしてみた。
      • https://diary.akane.blue/2020/01/26/db-repack-with-docker/
      • コマンド
        • docker-compose exec pleroma sh
        • /pleroma/bin/pleroma_ctl database prune_objects –vacuum
        • docker-compose exec pleroma_postgres bash
        • pg_repack -U pleroma -d pleroma -a
      • そもそも、データベースがでかすぎる。
      • 過去のデータを7日分にして、やっと5GBぐらい空きがあったらrepackできるらしい。
• 26
  • 家計簿
    • 続きをやろうとして、NASから手元にコピーしたら、手元の方が新しかった。
      • しかも、ホームディレクトリのバックアップが正常に動いてなかった。
      • つらみ
    • pocketcardの履歴もインポートしてみた
      • 使ってないつもりだったが、意外と使ってた。
    • 一括で仕訳したい。
      • RubyでREXMLで編集してみる。
      • Pretty printすると戻せないみたい。
      • uniq -cしてみたけど、多くても12件。イマイチ