piu lentoの日々 (piu lento days)

使っているデビットカードがGoogle Payに対応したので登録してみた。スマフォのカメラでカードを写すと番号などが自動入力されて楽だった。

ただ、有効期限とセキュリティコードは入力されなかった。セキュリティ上の問題があるから わざと出さないのかも知れない(でないと、他人のカードを写して登録できてしまうかも知れない)。

それから早速コンビニで使ってみたら、なぜか認識されなかった。セミセルフレジでクレジットカードのカテゴリのボタンを押したのだが、そうでなく、Google PayやApple Payなどのカテゴリ(PayPayなどと一緒?)があって、それを指定すべきだったのかと、あとで思った。

が、気になるので調べたら、クレジットカードのカテゴリでいいようだ。ただ、ページの下のほうに、小さく、スマフォがスリープ状態の場合は駄目みたいなことが書いてあって、それかと思った。それで、次の日はスマフォを復帰させてからタッチしたら、みごとに使えた。決済時にスマフォの画面にカードの絵が出た。どうやら、QUICPay(スマフォがどういう状態でもタッチすればOK)とは違うようだ。

そういえば、SuicaもGoogle Payに入れているけど、自販機などで使えた試しがないのは、長期間使っていなくて停止されている以外に この問題もあったのかも知れない。

↑ 試したら、スマフォの電源をonにしても使えなかったので、Suicaは電源に関係ないけど、長期間不使用で停止されていることが分かった。それにしても、駅に行かないと解除できず、いつも面倒だ。なぜ そんなことするのか全然理解できない。 (5/24 18:05)

いや、Google Payのデビット(クレジット)カードは仮想クレジットカード番号というものを使うらしいので、それで決済時にアプリが動く(= スリープ状態でない)必要があるのかも知れない。

タッチの前に いちいちスマフォのボタンを押すのは、なんか面倒だ。他にも、セルフレジでない場合には、店員さんにタッチ決済を理解してもらうのが大変な場合がある※のに、カードも出さずに(スマフォを出して)「クレジットカードのタッチ決済」とか言っても なかなか厳しい気がする。おまけに、店によっては(タッチする場所があるのに)クレジットカードは挿し込むしかない場合もあるので、こっちの頭の切り替えも煩雑だ。

※タッチ決済と普通のクレジットカード決済の操作が同じか違うか店によって違うし、タッチ決済できるのに、できないと思い込んでいる店員が居て難儀したこともある。そもそも、「クレジットカード(決済)で」と言うのが面倒だが、「カード(決済)で」だと別のカード(例: 店の電子マネー)と思われる可能性すらあり、クレジットカードのタッチ決済のハードルは高い。更に、少ないものの、クレジットカード=デビットカードでない店もあるから大変だ。

そう言えば、以前、上のような背景(タッチ決済できないと思い込んでいる店員の居る店)で、きちんと「クレジットカードのタッチ決済で」と言ったら、店員さんが褒めてくれた。「何種類もあるから、言ってもらえると助かる」みたいなことを言っていた。

あと、カードはスマフォでタッチ決済しても紙のレシートは来るので、それを財布に仕舞うという間抜けな面倒もある。

以前も書いたように、「電子レシート」がスマフォに届けばいいのだが、まだそこまでは無理か。

更に、どういう訳か、Google PayなのにGoogle Payの管理ページ(webまたはアプリ)には出ず、(Googleでない)通常のデビットカードの管理ページで見るしかないようで、どういう管理・仕組みなのか謎だ。

そんな感じなので、果たしてGoogle Payでデビットカードを使う意味はあるのかと思って居た。が、カードを財布から出さずに済むし、結果として挿したまま・置いたまま忘れることもないのは(僕には)大きなメリットだと考え※、使い続けることにした。

※実際、今までに数回、挿したまま帰ろうとしたことがある。

そうしたら、今日、すごいメリットがあることに気付いた。: デビットカードを使うとメールで通知が来るのだが、カード会社の仕様なのか、店名が書かれておらず(数日後に管理ページを見ないと分からない)、金額と日時程度だ。が、Google Pay(のデビットカード)で払うと、ちゃんと店名(ただしローマ字)が出るのだ。

店名が出るのはいいが、同じ仕組みで やれば出来ることがGoogle Payでしかできないのが不思議だ。Google Payは処理が高速とか、即座に検索できる加盟店一覧のDBを持っているとかいう話なのだろうか。

同じような操作だけど実は処理経路が違っていて、Google Payの場合は、「Googleのクレジットカード処理」(仮想クレジットカード番号を本物の番号に置き換える関係?)※を通すために、すぐに店が分かるのかも知れない。その情報をデビットカードの会社に通知するから、メールに店名が書かれるのか。

※その処理の時、店が正当かどうかも確認せずに素通しする訳にも行かないから、決済のたびに店のIDをチェックし、その時に店名も出るのか。そういうチェックは普通のデビットカードでもしているはずだが、店名まで検索していると遅くなるから ちんたらあとでまとめてやっているのだろうか。

(何はともあれ)細かいことだけど、使った直後に店まで確認できるのは かなりのメリットだ。実は、そのデビットカードを申し込む時に説明(店名が分かるのは数日後)を読んだ時から、ここを何とかして欲しいと思って居たのだ。

という訳で、いろいろな面倒はあるものの、二つの大きなメリットがあるので、使えるところでは(多少は我慢して)Google Payのデビットカードを使うことにした。

(5/24 8:02 少し修正・加筆)

デスクトップPCのクラウドストレージへのバックアップに、Backblaze B2 (以下、B2)に加えてGoogle Cloud Stroage Archive (以下、GCSA)も使うのを開始してから約半年経った。

B2は変更頻度の高い「新しいデータ」のバックアップに、GCSAは基本的に変更しない「古いデータ」や大容量データ(音楽など)のバックアップ(アーカイブ)と、階層的に使っている。

特に問題はない。

だけでは 余りにも ざっくりし過ぎだが、本当にそうなのだ。あえて書くとすれば、一つだけ心配なこととして、GCSAに保存しているデータを いざ使おうとしたら「駄目」になっていた※とかいうことがないかである。が、こればかりはどうしようもない。抜き出してチェックするにしても、頻繁にするとアクセスの料金(結構高く付く)が かさむためだ。まあ、Googleとバックアップに使っているソフト(duplicacy)を信じるしかない。

※GCSA: 「すまん、いつの間にかストレージが おかしくなってたわ」的な・・・

ちなみに、今まで4年くらいB2でduplicacyを使っており、(ヘマして消してしまったファイル)少量を数回リストアしたことがあるが、問題が起こったことはない。もちろん、バックアップでもduplicacyに起因する大きな問題は起こっていない。

以下、データ量・料金や気付いたこと・事前の想定と違ったことなどを書く。GCSAと一緒に使っているB2についても書く。なお、B2にはデスクトップ以外にサーバのデータもバックアップしているが、別ものなのとデータ量が小さいので以下には含めていない。

現在のデータ量と料金

• GCSA: 約946GB, 約150円/月 (税込み) → 年額見込み: 約1800円 (税込み)
  • 月によって追加バックアップをしたりするため、微妙に異なる。あと、為替相場でも変わる。
• B2: 約80GB, 約52円/月 → 年額見込み: 約630円 (現在のデータ量からの予想。USDで支払いのため消費税抜き(どういう扱いかは不明)。1USD= 130円とした。)
  • 正味のデータ量は約30GBなので、約20円/月 → 年額見込み: 約240円になるはず。
• 合計: 約1TB, 約202円/月 → 年額見込み: 約2430円

他のPC用バックアップサービスはデータ量無制限が多いので比較が難しいが、僕としては充分に安いと感じる。B2とGCSAを合わせた単価は約USD 0.0015(0.2円)/GB・月相当で、普通のストレージに比べれば随分安い(ただ、それらと同様に気軽にアクセスできる訳ではない)。

気付いたこと・事前の想定と違ったことなど

• GCSA
  • 日本法人を経由するためか、消費税が掛かるのを意識せずにいて、最終的に請求される料金が当初の想定より1割増えて、思わぬ落とし穴だった。
    • だったら、料金を円建てにして少しは為替変動を吸収して欲しいものだ。まあ、国からの指導(「(消費税含む)税金納めろ!」)※で やってるだけなのかも知れないが。
      • ※そういえば、AWSも日本法人からの請求になったようだ。
      • そうは言っても、(消費税の根拠・規則は知らないが、)海外にあるクラウドを日本で使うのは、国内で「消費」していると言えるのか疑問だ。どこが提供しているにしろ、何らかの役務を国内で利用しているから そうなのか。
      • だけど、海外の店から通販で買って輸入する場合には消費税が掛からないのとは矛盾する気がする。
      • まあ、専門家に聞くしかない。
  • 消費税だけでなく、近頃急に円安になったため、始めた時から結構(約1割)値上がりした。
    • 今のところ、日々の料金の増加は月の2/3くらいが5円、1/3くらいが4円になっている。
  • 当初は気付いていなかった使い方が分かって来た。
    • 料金を大きく増やさずに小まめに少量(例: 1GB以下)の追加バックアップすることが可能。
      • バックアップ前にしている整合性チェックを省けば良い。
        • 大体、1円/回+データ量比例分程度になる。(チェックありだと5円/回+データ量比例分)
        • 整合性チェックは、大量のバックアップをする時などにする。
      • → 今は、必要なら週末に追加バックアップをしている。意図せずに古いデータ領域に追加してしまうことが結構あるため。
        • それをうまく誤魔化す(別の場所に置いて何とかする)作業よりは、普通に一緒に置いてバックアップするほうが楽なので。
• B2
  • 正味の(事前に期待していた)データ量まで減るか、まだ不明。
    • 履歴(約6か月分)が保存されることもあり、正味のデータ量は30GBなのに対し、今月のprune(履歴削除)処理の前は その5.7倍(170GB)だったのが、prune処理によって2.7倍(80GB)にまで減った。
      • なお、GCSを使い始める時点では約450GB(うろ覚え)だった。
    • かなり減って料金は充分安くなったが、まだ「本物」ではない(正味のデータ量より随分多い)。
      • この増分は、履歴によるのかオーバヘッド(ファイルを削除したため、余計な部分が残って居る)なのか、まだ分かっていない。
    • 今後もprune処理で減るかも知れないので、もう少し様子を見ることにした。
    • もし減らなかったら、新しくバックアップし直すか、そのままか、安い方にする。

PS. 本文とは直接関係ないが、バックアップに使っているソフトduplicacyの問題らしきものが一つだけある。: デスクトップでなく、サーバ(VPS)だけで起こることだが、たまにduplicacyのprune(古い履歴の削除)処理が失敗することがある(「(pruneで削除しようとしている)チャンクがない」というエラーが起こる)。数か月に一回くらい起こる。

なかなか原因が分からなかったが、どうやら、clamscanの実行中にduplicacyでpruneかバックアップをすると起こるようだ(バックアップの場合は、そのチャンクがpruneされる時に起こるようだ)。試しに、clamscanの実行中はduplicacyの起動を延期し、逆にduplicacyの実行中はclamscanの起動を延期するようにしたら、起こらなくなった。

ただ、まだそれほど長く確認していないので、関係ない可能性はある。

clamscanの実行中は負荷が高く空きメモリが少ないので、duplicacyの処理やB2のサーバへの通信が異常になってしまうのかと想像しているが、確証はない。また、この問題はデスクトップでは起こらないので、サーバのVPSとの相性のようなものかも知れない。VPSはメモリ量が少ないのでその関係だろうか?

そういえば、プロバイダの保守でVPSのプラットフォーム(ハード+ホスティングソフト?)が更新されてから起こるようになった覚えがあるので、VPSとの関係がありそうだ。どこに聞いたらいいか分からず、難しい。

PS2. 同じくGCSとは関係ない話。: duplicacyに問題はないが、いくつか不満はある。例えば、資料が今一つ(基本的なものはあるけど不充分で、残りはフォーラム(作者(と それらしき人)がtipsとして書いているものが多い)を探して見るしかない)、使い勝手が今一つ(なんか ごちゃごちゃしている → 資料が不充分になる、やりたいことができるか・どうしたらできるか不明、できそうなことができない、バックアップ対象選択フィルタの機能が貧弱)とか、動作・中身が複雑で把握しにくい(→ トラブル時に調査・復旧しにくい)ことだ。

更に、調べていて偶然見付けた、未解決の問題が放置されているのも気になった。おそらくユーザーの使用環境に起因するのだろうが、放置する姿勢が良くない。

これ以外にも、ごく真っ当な修正要望(エラー時にも0を返すのは良くない)にも対応していない。 → 良く居る頑固な開発者のようだ。

そして、先日、別の稿に書いた認証情報の格納方法の件で他にいいもの(例: rcloneのように設定ファイルを暗号化できるもの)がないか探してみたら、duplicacyと同様なカテゴリのものでKopiaというのが見つかった。まだv0.10.7だけど、雰囲気や資料は良さそうなので、しばらく様子を見たい。ただ、これはストレージの認証情報をファイルに平文で書くので、そこが ちゃんとされない限り使えない。

それでも、試してはいないものの、Kopiaには(duplicacyと同様に)CLIとGUIがあるが、duplicacyと違ってGUIも(今は?)無料なので、手軽に使いたい方には いいかも知れない。あと、duplicacyと違って、バックアップストレージをマウントして中身に手軽にアクセスできるのは すごく便利そうだ。

(5/23 5:33 少し加筆・修正。PSを追加; 7時 PS2を追加)

先日気付いた(というか、それまでは「まあいいか」にしていた)、バックアッププログラム(duplicacy)が使うクラウドストレージの認証情報とバックアップデータの暗号鍵(以下、認証情報)が平文で保存されていた件。デスクトップはGNOME keyring(以下、GKR)を使って何とかできたが、サーバが難しかった。

というのは、デスクトップと違ってサーバには通常はログインしないので、GKRをアンロックする(= パスワードを入れる)契機がないのだ。前回書いたように、そのパスワードをサーバに安全に保存するのは難しい(それを暗号化して保存するとしても、そのための鍵・パスワードをどうするかになって、キリがない)。

「普通」は どうしているのか気になるが、少し調べても分からなかったので(前回書いたように、今だとTPMを使っているのかも知れない)、自分なりに何とかした。

以下のような骨組みにした。

• デスクトップと同様に、クラウドストレージの認証情報はGKRのキーリングに保存する。
  • キーリングのパスワードはサーバには置かずに管理(記憶または保管)する。
• サーバが(再)起動後はキーリングがアンロックされていないので、認証情報を使うプログラム(具体的にはクラウドストレージへの自動バックアッププログラム)は失敗する。
  • 失敗するとメールで通知が来る。
  • サーバは基本的には再起動しないが、自動更新の内容によっては再起動する。
    • 再起動はそれほど頻繁ではない(ただし、連続する場合もある)。
• 失敗の通知が来たら、僕が手で(デスクトップから)サーバのキーリングをアンロックする。
  • アンロックするまで自動バックアップされないが、バックアップは数時間ごとなので、僕が「ちゃんと」して居れば大きな問題にはならない。
  • 今はありそうもないが、長期の外出中にサーバが再起動した場合などにはアンロックできずに問題になりそうなので、その時に考えたい。
    • アンロックするには、パスワードがあってサーバにsshできればいいので、いざとなればスマフォでもできそうだ。
      • → 試したらできた。: Androidのターミナルアプリ(Termiusを使った)でsshでサーバにログインし、アンロックプログラム(gkr-unlock.sh)を起動し、パスワードマネージャ(KeePass)からキーリングのパスワードをコピー・ペーストして入力すれば良い。最後の方に載せた画面例と同様の操作である。 (5/24 9:09)

上の仕組みを実装し、どうにか動くようになった。細かい点を以下に書く。

• デスクトップと異なり、認証情報はGKRのログインキーリング(以下、キーリング)に格納される(デスクトップはデフォルトキーリング)。
  • GKRの仕組みを完全に理解していないせいもあるが、seahorse(GUIアプリ)を使わずにアンロックできるのは、(現在は)ログインキーリングだけなので、仕方ない。
    • gnome-keyring-daemon --unlockでログインキーリングをアンロックする。
    • 昔は任意のキーリングをアンロックするプログラム(pam-keyring)があったようだが、なぜか なくなってしまった。
      • GNOMEのLibsecretのAPIを使えばできそうで、試したらデフォルトキーリングのアンロックはできたが、「ちょっと試す」以上だと複雑かつ情報が少なくて、任意のキーリングについては途中で挫けた。。。
  • 認証情報はデスクトップのデフォルトキーリングの用法にならい、属性serviceとusernameで種類を識別・区別できるようにした(要するに、同様に格納した)。
    • サーバではseahorseが動かないので、キーリングの初期化と認証情報の格納にはgnome-keyring-daemonとsecret-toolを用いた。
    • 以下の手順でキーリングを初期化・格納した。
      1. 既存のキーリング(~/.local/share/keyrings)を使わないなら削除する。
      2. dbus-launch --sh-syntax のようにしてdbus-daemonを起動する。
      3. 上で表示された文字列(DBUS_SESSION_BUS_ADDRESS=...を実行して、Dbusの環境変数を設定する。
      4. echo -n パスワード | gnome-keyring-daemon --unlock のようにして空のキーリングを作り、パスワードを設定する。 (既存のキーリングの場合は単にアンロックする。)
      5. secret-tool store --label="ストレージ名" service アプリ名 username ストレージID のようにして、それぞれの認証情報を格納していく。
  • 作成したキーリングをアンロックするプログラム(gkr-unlock.sh)は、アンロック後、GKRにアクセスするのに必要なDbusの環境変数(DBUS_SESSION_BUS_ADDRESS)をファイルに保存する。
  • この辺りの基本処理のコードを以下に示す(実際とは若干異なる)。dbus-launchがGKRにアクセス可能なDBUS_SESSION_BUS_ADDRESSを設定するので、それをファイルに保存する。

echo "$PW" | dbus-launch
sh -c "gnome-keyring-daemon --unlock -d -r;
echo export DBUS_SESSION_BUS_ADDRESS=
\$DBUS_SESSION_BUS_ADDRESS
> $dbus_env_save_file" >&- 2>&- &

※見やすくするため改行したが、実際には全部が1行である。

※$PWには あらかじめ入力したキーリングのパスワードを、$dbus_env_save_fileには環境変数を保存するファイルのパスを格納しておく。

• 認証情報を使うプログラムは、secret-toolでキーリングにアクセスする。
  • デスクトップと異なり、Dbusの環境変数が設定されていないため、そのままではアクセスできないので、環境セットアッププログラム(setup_dupl_agk.sh)経由で起動する。
    • デスクトップのcrontabでの実行時も同様なので、デスクトップと同じ環境セットアッププログラムが使えるようにした。
  • 環境セットアッププログラムは、上記のキーリングをアンロックするプログラムが保存したDbusの環境変数を読み込み・設定・exportして、目的のプログラムを起動する。
    • なお、dbus-daemonやGKRを起動したユーザー以外(具体的にはroot)はGKRにアクセスできないようなので、バックアッププログラムが使うクラウドストレージの認証情報をキーリングから取得し、環境変数に設定・exportしてバックアッププログラム(duplicacy)が使えるようにする。
      • duplicacyは、設定ファイルやGKRだけでなく、環境変数からも認証情報を取得できる。
    • Dbusの環境変数を保存したファイルは再起動すると なくなるので、再起動後は自動的に失敗する(古い無効な環境変数でアクセスして、おかしくなることはない)。
• デスクトップからは、サーバのキーリングをアンロックするプログラム(gkr-unlock.sh: サーバと同じもの)を実行する。
  • gkr-unlock.shは、sshでサーバに接続して、サーバ側のキーリングをアンロックするプログラム(gkr-unlock.sh)を起動する。
  • 基本的には、サーバでgkr-unlock.shを起動するとキーリングのパスワードを要求して来るので、(手で)入力してアンロックする。
  • ただ、毎回パスワードを手で入力するのは面倒なので、サーバのキーリングのパスワードをデスクトップのキーリングに入れておき、アンロックするプログラムはそのパスワードを自動で取得してサーバに送るようにした。
    • そのため、サーバのキーリングのパスワードを複雑なものにできる。
    • また、アンロック時はサーバにssh接続するための鍵のパスフレーズを入れるだけで良い(sshエージェントを使えばそれも不要になるとのことだが、それはしていない)。
    • sshエージェントを使えば、サーバの再起動を検知したら自動でアンロックすることも不可能ではないだろう。
    • そのため、サーバのキーリングのパスワードはパスワードマネージャ(Keepass)とGKRの2箇所に重複して保管されて管理の点で良くないが、利便性のためなので「仕方ない」とした。

いつものように、今回作ったGKRアンロックプログラムは思ったより複雑になった(その前に作った環境セットアッププログラムはもっと複雑だ)。僕が求め過ぎるためにそうなるのか、もっと単純・簡単な方法があるのか、今は分からない(そして、「ちゃんと使えれば良し」で そのままに・・・ｗ)。

以下に、デスクトップからサーバ(ホスト名をserverとする)のキーリングをアンロックする画面(?)の例を示す(一部を変更した)。起動後、"Enter passphrase-"のところでssh鍵のパスフレーズを入れる。"bin/gkr-unlock.sh"で始まる行はサーバ側のアンロックプログラムの出力である。

$ ./gkr-unlock.sh server
./gkr-unlock.sh: Obtaining remote host server's GKR password: attrs.: service=gkr-unlock, username=server.
./gkr-unlock.sh: Executing on rem_host: server: bin/gkr-unlock.sh
Enter passphrase for key '/home/user/.ssh/server_id':
bin/gkr-unlock.sh: Enter GKR password (empty to abort):
bin/gkr-unlock.sh: Starting dbus-daemon and gnome-keyring-daemon...
bin/gkr-unlock.sh: Saved dbus-env. to /run/user/9999/dbus-env.
bin/gkr-unlock.sh: Succeessfully unlocked GKR.

DbusやGKRのプロセスを停めて基本的な確認はしているものの、まだ、実際にサーバを再起動して そのあとの復旧(再アンロック)手順に問題がないかを試して居ないので、何か問題が起こりそうだ。早目に再起動して確認・対処することもできるが、(面倒だしｗ、)通常はちゃんと動いているから 自動更新での再起動を待っている(そして慌てる)。

→ (5/26 6:40) 今朝、自動更新での再起動があり、(意外にも?)想定した復旧(再アンロック)手順で うまく行った。

セキュリティを改善できたものの、(詳しくないなりに考えると)気になることは ある。

• 基本的にキーリングは常時アンロックされたままなので、システムに侵入されて、ユーザー権限が取得されてDbus関係の環境変数が分かれば、GKRに接続できて認証情報を取得できてしまう。
  • デスクトップでも同じことではあるが、サーバだと更に心許ない。
  • ただ、ユーザー権限が取得されても「大丈夫」なように防御するのは大変難しい(SE Linuxを使いこなす必要があるのではないか。それでも完全かは分からない)ので、「仕方ない」とした。
  • それでも、この対処をすることで、認証情報が平文で設定ファイルに保存されなくなったので、仮に設定ファイルが流出しても被害が少ないという点で意味がある。
    • まあ、本当に「最低限の対処」をしたということだ。
  • その点で、GKRを信頼し切って、全部の認証情報を格納する「パスワードマネージャ」として使うのは良くないと思う(実際に、僕はそうしていない)。
    • gpgにはアンロックのタイムアウトがあるので良いが、サーバでは使いにくい。
    • 書いたあとで思い付いたが、認証情報を使うたびにアンロックするようにするのがベターかも知れない。
      • その時のパスワードは、動き続けるプロセスが保持するようにする。そのプロセスのメモリを読まれない限り、安全だろう。
      • とは言え、ユーザの権限を取得されれば駄目だし、そのプロセスはアンロックされたままのGKRと同じことか。

サーバではないけど、スマフォの権限の制限がAndroidですら厳しい(僕にしてみれば「Linuxなのに何もできない」)のは、こういうことに起因するのだろうと思った。

それから、クラウドストレージに関しては改善できたが、気になるものは他にも いろいろある(例: ブログサーバプログラムの設定ファイル)。簡単にはできないので、いい案を思い付いて やる気があれば着手したい。あるいは、既存の何かがあるかも知れない。

まあ、まず、一般的なサーバでは「普通」はどうしているかを調べるべきかも知れない。

SE Linuxだけど、手に負えなくて「全部解除」とかいうオチだったりはしないよね?ｗ

数か月前に、メモリ使用量が多くなってしまったFirefoxに見切りを付けてVivaldiに乗り換えた。ところが、それから少ししたら、なぜか、Vivaldiのメモリ使用量も多くなってしまった。丁度Chrome(Chromium)の更新後だったので、うまく整合しなくなったのかと推測し、少し経てば直ると思って居たのだが、直る気配は なかった。Vivaldiがメモリリークしているのかと思って調べたが、そういう情報はなかった。

結論を先に書くと、メモリリークのようなVivaldi自体の問題ではないが、特定のChromeのアドオン(Chromeでは"extension"だが、ここでは「アドオン」と書く)とVivaldiの相性の問題のようだ。: 具体的には、アクティブでないタブを自動でサスペンド(Chromeでは"discard"?, Vivaldiでは"hibernate")するアドオン(The Great Suspenderなど)で、どういう訳か、その「Chromeの内蔵省メモリ機能を使う」設定が うまく動作しなくなる(逆に動作するように見える)のが原因のようだ。

なお、メモリ管理はLinuxとWindowsなどでは異なるだろうから、この現象は おそらくLinux版特有と思われるので、そういう題にした。

現象は、Vivaldiを起動後 数時間から数日経つと、メモリ使用量が増大する。僕は約240個のタブを開いているが、アドオン(オリジナルのThe Great Suspender)でタブを自動サスペンドしているため、通常はメモリ使用量が10GBを超えることがない。それが、ある時に10GBを超えてしまい、何もせずに(タブをアクティブにしない)待っても減らないのだ。

Vivaldiは諦めたくないので※、どういう時にメモリ使用量が増大するか頻繁にチェックしていたら、メモリ使用量が増大している時はプロセス数(≒ アクティブなタブ数*k(1.5辺り?) + B(10辺り?))も多くなっている(例: 80以上)ことが分かった。＊ それで、定期的(15分ごと)にVivaldiのプロセス数とメモリ使用量を記録・チェックしてみたが、切っ掛けは分からなかった。

※実はちょっと くじけてｗ、(省メモリの評判がある)Edgeを試したが、Windows版には あるらしい省メモリの設定がLinux版には なかったので、すぐに止めた。

＊アクティブでないタブがサスペンドされなくなるのか、サスペンドしたタブ(のプロセス)がゾンビのように復活するのだろうかと想像するが、詳細は分からない。

それから、表示するページやVivaldiの設定やアドオンに関係するかと考えて、原因になっていそうなページを開いてメモリ使用量の増加を調べたリ、Vivaldiの設定を変えてみたり、ほとんどのアドオンを無効にしたり、タブを自動サスペンドするアドオンを換えたり、そのアドオンの設定を変えてみたが、改善しなかった。

それで、駄目元(と言うか破れかぶれ)で、自動サスペンドするアドオン(今はThe Marvellous Suspenderを使っている)の設定"Apply Chrome's built-in memory-saving when suspending"(以下、「省メモリ設定」)をoffにしたらどうなるか試してみた。

VivaldiでThe Marvellous Suspenderの省メモリ設定(下側)をoffにして試した。

この設定をoffにすると、タブのメモリが「うまく」解放されないだろうから、メモリ使用量が更に増大して とんでもないことになるはずだから普通はしないが、「onにしても増大するなら、offでは 一体どのくらいひどくなるのか見てやろうじゃないか!」と思ったのだ。

すると、いつ「とんでもないこと」が起こるかと待ち構えているうちに忘れてしまい、気付いたら問題が起こらなくなって居た。信じられないことだが、再度 省メモリ設定をonにしたら現象が起こったので、どうやら これが原因だったようだ。

今も半信半疑で使っているのだが、Vivaldiを起動してから6日くらい経っても現象は起こっていない。

5/18 9:13 プロセス数: 41, メモリ使用量: 5.5GB (平均: 133MB/プロセス)

どうしてアドオンの省メモリ設定が逆になる(正確には「逆に働く」)のかは分からない。想像だが、元々Vivaldiは(Chromiumに対する)その設定をonにしていて、アドオンでもonにすると、設定が反転したり動作が無効になってしまうのだろうか。

フォーラムに出せば何か分かりそうだが、Vivaldiのフォーラムかアドオンのフォーラム(あれば)か、どちらに出せばいいか不明だ。あと、他の方が特に文句を言っていないのも気になる。そういう場合は僕の環境に問題があることがある。

なお、省メモリ設定のないアドオン(確か、Auto Tab Discard)でも現象が起こったので、設定があるもののonに相当するのだろう。ちなみに、本物のChromeでは現象が起こらない(オリジナルのThe Great Suspenderが ちゃんと動く)ので、Vivaldiに何かありそうだ。あるいは、ChromeとChromiumに違いがある?

書いたあとで思い付いたのだが、Vivaldiにはタブをhibernateする機能がある(惜しいことに自動でない)。それで、アドオンがタブをChromeの省メモリでない方法で「サスペンド」すると(そういう機能があるのかや、それに意味があるのかも不明)、うまい具合にVivaldiのhibernate機能が使われて、メモリが「うまく」解放されるのだろうか? 逆に、Chromeの省メモリでサスペンドすると、Vivaldiの管理とズレてしまって うまく解放されないことがあるのかも知れない。

とりあえず うまく行って良かった。もうしばらく様子を見たい。フォーラムは疲れる(気力が要る)ので、覚えていて余力がある場合にするｗ

↓

(5/27 6:07) その後 メモリ使用量の増大は起こっていないので、解決したようだ。 (→ 題を更新した。)

おまけ (5/23 5:03)

(メモリ使用量には関係ないが、Vivaldiとアドオンに関連するので書く。) ブラウザのウインドウに任意の文字列を追加するアドオンWindow Namer and Restorer BETA(以下、Window Namer)はKeePassXC用のアドオンKeePassXC-Browserと相性が悪い。どういう訳か、KeePassXCが取得するタブのURLが(同じウインドウの)別のタブのものになってしまうようで、KeePassXCから別のURLに対する認証情報を取得してしまう。

近頃、ID・パスワードが自動入力されない、あるいは、別のサイトのものが入力されることがあって、おかしいと思って調べたら、Window Namerが悪かった。

Window Namerで ウインドウの名前にカテゴリ(例: "[News]")を付けることで、複数のウインドウの区別が楽になって便利だったが、KeePassXCが誤動作するのは かなり不便なので使うのを止めた。

なお、これはVivaldiだけで起こる問題なのか、Chromeでも起こるのかは不明(未確認)。

PS. そういえば、Firefoxでも同様な現象が起こっていたが、まあ、あっちは構造も仕組みも全く違うから、単に腐ってメモリリークしているだけなのだろう。。。

PS2. 本題には関係ないが、Ceronでちらっと目にした、「検索にクソブログしか出て来なくてムカつく」とかいう件について書く。

まず、そのスレに書かれていた、最後に「いかがでしたか?」と出るのは ブログでなくアフィリエイトや まとめサイトだ。一緒にしないで欲しい。そして、ブログやWordpressサイトをひっくるめて「クソ」と言われたり、一括して検索結果から除外したいとか言われるとムカつく。まあ、ブログサイト全体を平均すると役に立たないものが多いだろうが(でも、今はアクティブなサイトが減っているから、アクティブなものだけなら有用なものが多い気はする(希望))。

個々のブログサイトの質、検索結果に出て来る候補のマッチ度合いは玉石混交だけど、それは(昔の)図書館などで目的の情報を探せるかどうかに似ている気がする。: 検索する側の能力・努力や探す気力・情熱も関係するのではないか。

細かい経験則として、英語でも検索すると、目指す答えに近付く可能性が高まることはある。個人的には、分野によるが、コンピュータ関係は英語のほうが ずっと効率が良い気はしている。

とは言え、英語のサイトにも、新しいページに古い情報をそのまま載せていたり、他サイトのコピペや最後に「いかがでしたか?」のような類のクソは多いので、安心はできない。

そして、自分で碌に考えも試しもせず、ちょっと検索してパッと「答え」を得ようとするのは安直過ぎると思うし、それでは無理だ。「そんなに世の中は甘くない」だ。そもそも、今は昔よりずっと情報が多いではないか。

なぜか僕は臭いにも敏感になってしまい、日々闘っているｗ

とは言え、鼻は良くない(いつも詰まっている)し、自分の臭いだって いろいろあるはずだけど、そういうのには気付かない(たまに、通常とは違う狭い空間に行くと気付くことがある)から、相対的とか主観的な話だ。

近頃は、(以前から書いている)部屋の異臭(外から来る煙草、薬品・農薬のような臭い)が、いろいろな苦労の末に どうにかなりそうだけど、まだ気が抜けない状態(効果の確認中)だ。それとは別に、以前から嫌だった別な臭いに対処した。

それは、一時使っていた(けど、いろいろ ひどいので止めた)iVideoというモバイルプロバイダのレンタルWi-Fiルータなどのソフトケースに付いていた臭いが しつこくて、全然抜けないことだ。: 旧居から引越す前後に使っていたので2年以上経つのだが、引越しの時の梱包で その「臭いケース」を入れた段ボールに一緒に入っていたコード・ケーブル類に臭いが付いてしまって消えないのだ。

更に、引越しの日に、ルータのケースを一時的に車に入れていただけなのに(コード類の箱は大きいから車に載せなかったはずなので上の記述と矛盾するが、貴重品なので気が変わったのか別の時に入れたのかも知れない)、車内にも臭いが付いてしまい、つい近頃まで抜けなかった(今も わずかに臭うことがある)。

ちなみに、引越しの前も その「臭いケース」に困ったので、密封した袋に入れて保管していた。上記の梱包や車に入れる時もそうして居たはずだが、気を抜いたのか、狭い空間で溜まったのか分からないが、臭いが漏れてしまったようだ。

それから、コードの被覆は主に軟質塩ビで、特有の臭いがあると言われているが、僕は気になったことがない。これは、そういう素直な・生易しいものでは ない。

どういう臭いか表現が難しいが、近頃検索して分かったのは「クッサい香水」だ。香水ほど強くはないが、周りのものに まとわり付いて離れない嫌らしい臭いだ。妙なことに、臭いに手触りがあるようで、それに侵されたコードは変な手触り(粘り気のない油っぽさが手に まとわりついて、気持ち悪い)に成り果てて居る。

昔のドラマ風に書くと、「お前なんて うちのコードじゃない! 出てけっ!!」、あるいは、「この薄汚ねえコード、どっから来た!!」って感じだ。全く。

iVideoの発送担当者が そういう下品な香水などを付けていたのか、返却後にケースに散布したと思われる除菌スプレーの類※が そういう臭いだったのかと想像している。

1回だけでなく、数回レンタルした時のケース全部が臭ったので、たまたまではない。

※書いたあとで気付いたが、歯科に行ったら 問題の臭いに似た臭いが身体に付いたので、除菌スプレーの類ではないか。まあ、歯科でどういう薬剤を使っていて、どれがその臭いなのかは不明だが。 (5/18 15:06)

今の家では、その臭いコード類は 口を少し開けた押入れケースに入れておいて、臭いが発散して消えるのを期待していたのだが、丸2年経っても消えないので、業を煮やして何とかしたくなった。

確か、以前も(全部か一部か忘れたが、)水で拭いた気がするが、効果はなかった。ケースの口を少し開けるようにする前には中に脱臭剤を入れて居たが、その効果もなかった。

以下の順に試行錯誤した。4のウォッシャー液までは効果がなかったため、作業を追加して行った。

1. 全部を台所用除菌アルコールで拭いた。
2. 窓際に干した。
3. 臭いの消えない数本に掃除用ウェットティシュー、車の洗剤、液体石鹸を試し、効果を比較した。
4. 全部を車のウォッシャー液で拭いた。
5. 窓際に干した。
6. 臭いの消えない数本を湯(約60℃)に漬けて試した。
7. どうしても臭いの消えないものを選別し、隔離した。

最初に台所用アルコールで拭いて干してみた。効果があるものはあったものの駄目なものも多く、今一つだった。それで、手元にあった掃除用ウェットティシュー、車の洗剤、液体石鹸を試したところ、ウェットティシューは少し効果があったが車の洗剤は全く効果がなく、石鹸は多少効果がありそうだったが、それ自体の臭いが付くので却下した。

なお、臭いの有無は、コードを折って平たいループにしたところに鼻を近付け、息を吸って確認した。それぞれのコードを同じ条件で調べるため、なるべく同じ量(長さ)のコードを嗅ぐ必要がある。

どれも今一つだったので、消臭方法を検索してみた。: 一番近いと感じたのは、ビニルのバッグに付いた香水の臭いの取り方だった(それで臭いの表現方法を思い付いた)。方法・使うものとしては、(濃い)アルコール、重曹、クエン酸、塩素・酸素系漂白剤、マイクロファイバーの雑巾、湯などが出て来た。アルコールは(濃度は薄いけど)試していたし、重曹やクエン酸はコードには使いにくいし、漂白剤は扱いにくいので止めた。マイクロファイバーは多少効く気がしたが、そのページは それらの宣伝だったので却下した。

それで、ふと思い付いて(何となく効きそうな気がした)ウォッシャー液を試してみた。成分を見ると、界面活性剤やメタノール※などとなっており、後者には結構危険を感じたが、換気に気を付けて試したら、まあまあ効果があったようだ(実際には、単に長時間干していた効果だったのかも知れない)。

※ウォッシャー液に(エタノールなどでなく)メタノールが入っていることは全く意識して居なかったし、そういうのを人や自転車やバイクも居る道路で噴霧していいのか、結構疑問だ。濃度が薄い訳でもなく、約17%(重量)だった。全部のウォッシャー液が そうではないのかも知れないが、そのうち健康被害の問題になるかも知れない。

なお、湯は熱湯で なかったためか、効果がなかった。長時間煮ないと駄目なのかも知れないし、仮に効果があったとしても、全部を処理するのは大変なので、却下した。

妙なのは、(どの方法でも)処理した直後は効果があっても、時間が経つと臭いがぶり返すことがあることだ。温度も関係しているようで、部屋が暖かくなる(大体25℃以上)と臭いが強く出て来る。それから、臭うコードとそうでないものを近くに置いても、臭いが転移することは少なそうだった。

あと、コードの被覆によって臭いの吸着力が違うようで、臭いが取れないコードが結構あった。例えば、EthernetのTPケーブルは概ね駄目だった。他に比べて被覆が薄い(成分が少し違う?)ことや、長いために臭い成分が付く量が多いのが関係あるのだろうか。あと、JVCやソニーを含むピンコードや、パナを含むACのテーブルタップのコードも駄目だった。これも成分の関係か。そして、いかにも被覆の厚いAC電源コード(3端子のもの)は駄目だった一方で、なぜかUSBケーブルは優秀(「臭いが消えた」の意)だったので、被覆の厚さよりも成分が関係して居そうだ。

そういえば、一緒に入れていた機器(ポケットWi-FiやPCファン)のケースなどやコード類を入れていた押入れケース(PP?)自体は臭くなかったので、軟質塩ビが臭いを吸着しやすいのかも知れない。

一週間近く拭いたり干したりしても埒が開かないので、臭いの消えないものは諦めて隔離し、袋に入れて保管することにした。捨てたいところだが、結構量が多く(全部の1/3-1/2くらい)て もったいないので、他にない時に使えるように そうした。

良くない例えだが、この臭いは、放射性物質同様に半減期が長いのではないだろうか? 少なくとも10年は ありそうだ。その「仮処分」方法も似ている・・・

臭いの有無で分けたコード類は、一旦 元の押入れケースに収めたのだが、通気が悪そうで 臭い(消えたと思っても微妙に残って居るはず)が籠もって減らなそうだったので、段ボールに入れ、上面を開放してある程度通気するようにした。それを机から離れた場所に置いた。

これで一旦終了だが、少し経ってから臭いがどうなっているか、調べてみたい。

でも、「臭いコード」は見たくも ないな・・・

iVideoには本当に懲り懲りだ!

(5/17 12:55 わずかに加筆)