Category: Linux

zram (6) 小メモリーには不適かも

これまでZRAMを信奉して，現在使用している全てのLinuxの実マシン（Manjaro AMD64, Debian AMD64, Raspberry Pi 3/4/5 Model B）と仮想マシン（AMD64, x86 32bit各種ディストロ）に採用してきました．

それらでは特に目だった問題はなく，パフォーマンス的にもファイルやパーティションを使用するものより少なくとも悪くはないと感じています．

現在ちょっとしたきっかけがあってRaspberry Pi Zero 2 WHで遊んでいます．

Raspberry Pi Zero 2 WH

今日のわが家でRaspberry Piが担う一番の仕事は，防犯カメラの出力するRTSPをHDMI端子でつないだ地デジテレビに再生することです．

紆余曲折ありましたが，現在はVLCを使うことに落ち着いています．この仕事はRaspberry Pi 4 Model B (RPi4)ならば余裕です．何日間も安定動作してくれます．

Raspberry Pi 3 Model B / B + (RPi3/RPi3+)では良くて一日持つくらいで，たいてい一日に2〜3回VLCが落ちます．筆者はともかく家族が利用するには不適です．

それでRaspberry Pi Zero 2 (RPi02)ではどうかというと，数時間もつこともありますが，数分で落ちることもあります．

それが，ZRAMでは全然だめで，そもそもVLCが起動しません．Raspberry Pi OSのデフォルト設定である/var/swapを使用したファイル swap (dphys-swapfile)ではその数分から数時間という状態です．

RPi02のCPUはRPi3と同じARM Cortex-A53でクロックが1200→1000MHzに落とされているのが違いなのでたぶんメモリーが少なすぎることがこの安定性の差だと思われます．

ひょっとすると，RPi3 (+)の現在の不安定性（1日に2〜3回VLCが落ちる）もZRAMからdphys-swapfileに戻すと解決するかもしれないのでやってみます．

ただし，客観的に示せるようなデータはないです．

RPi3の不安定性 (3)

その後のRaspberry Pi (RPi)の安定性です。鉄壁の安定性を誇るRPi 4のmicroSDカード(SDカード)をクローニングしたRPi 3+はその鉄壁の安定性を受け継ぎ、今のところVLCによるRTSP動画再生のフリーズはありません。

一方SDカードを新品と交換することで安定性が増加したRPi 3については、1日に数回フリーズと言う事はありませんが、1日もちません(半日内外でフリーズする感じ)。

これを改善するにはそれこそ鉄壁の安定性を誇るRPi 4のSDカードをこちらにもクローンニングすればいいわけですが、そうすると多様性が失われてしまいます。もし次に何か重大なトラブルが起きたとき全滅と言うことになってしまいます。

しかしその時はその時でクリーンインストールをすればいいだけの話で、今回は多様性を無視して全部クローンと言う形にして解決することにします。

実際にはいろいろいじりながらなので今のところ1日以上連続運転することはないのですが，その間フリーズはありません．

Manjaroの弱点

筆者の愛用しているManjaroはrolling release modelというバージョンアップの方法を採用しています（ベースのArch Linuxがそうであるため）．

まあ，GentooやSlackware-currentも同様ではあります．この手のdistroの弱点は，しばらくupdateをしないで放置しておくと通常のupdateの手段ではupdateができなくなってしまうことです．

実マシンから作ったディスク仮想イメージとして存在させている仮想マシンは，もとの実マシンのバックアップ的な意味合いなので存在感が薄く，気がつくと最後の更新が何か月も前だったりします．

筆者のLinux第一WSであるManjaro AMD64も，ときどきバックアップのためにディスクを仮想化して仮想マシンに仕立ててます．仮想マシンとしても実は一番気に入っているので，Mac mini2台と実マシンであるManjaroのWS自身の中で仮想マシンとして “飼って” います．

気に入っているとは言えバックアップなので新し味がなく，ときどきupdateが何か月ぶりになってしまうことがあります．そんなときは他のupdate可能なイメージをコピーしたり，新たに実マシンから仮想化しました．パックアップの更新としての意義があります．

たまたま，前日updateができなくなった状態をあるSNSに投稿したら，親切な方が，

pacman-key --refresh-keys
pacman -Sc

を試してみてはと教えてくださいました．

一台目はそれで復活しました．しかし，別の仮想マシンが同様の症状になっていましたが，上記の方法では復活できませんでした．1勝1敗です．

NGなほうはさらに別のマシンで動いているupdate可能なManjaroのディスクイメージをコピーして差し替え，動くようになりましたが，バックアップの意味を込めて後で久しぶりに実マシンから仮想化しようと思います．

筆者はシステムのメンテはrootでログインした状態で行うことをポリシーにしています（Slackware流）ので，コマンドごとにsudoを使う事はしません．

バックアップの削除でサーバーが無応答に

現在サーバーのバックアップは，バックアップの際にマウントする2TBのHDDに，前回からの差分をバックアップする形にしています．

rsyncでバックアップしています．今日の日付からなるディレクトリーをバックアップのボリュームに作り，ひとつ前の日付のディレクトリーを--link-destオプションで指定してサーバー内の全部（ただし，バックアップのボリュームのマウントボインや/tmp, /dev等は除く）をコピーすることで，変更がないファイルはハードリンク，変更があったファイルは新しいファイルをコピーするようなことを勝手にやってくれます．

rsyncは優秀で他のサービスに影響ありません．だいたい15分くらいで終わります．ただし，毎日毎日バックアップを続けると，だんだんハードリンクが長くなるせいか，バックアップに要する時間が長くなってきます．30分，1時間，ついには1時間越えと．

そこでときどき古いバックアップを削除します．手作業です．削除は普通にrmコマンドに-rオプションを付ければよいです．ただこれがなかなか重い作業で，rm自体はメモリーをほとんど食わず，SWAP領域が増えることもないのですが，kswapd0デーモンがかなりCPUサイクルを食います．何が起こっているかよく解らないのですが，ルートドライブもこのバックアップドライブもUSB接続だというのが良くないのではないかと今は推測しています．

昨日もずっとhttpdやその他のデーモンが動かなくなっていたのを知っていましたが，rmコマンドを途中でやめるわけにも行かず，一晩そのままにしておきました．

rmコマンドが終了しても，デーモン類はスタックしたまま自動的には復活しないので今朝システムごとリブートしました．

今後はバックアップの削除は他のWSにつないで行うことにします．

ATOK Passport 再契約

去年の7月にATOK Passportを解約して，無料で使える日本語入力ソフトのうち一番まともそうなGoogle日本語入力を使ってきました．Google日本語入力はMozcとも共通部分があるから，使い勝手がLinuxのいくつかのWSと通じるという利点も期待しました．

それから1年3か月ですがもう限界なので再びATOK Passportの契約をしました．

何が悪いかというと，連文節変換がバカすぎです．なかなか実例が思い出せませんが，連文節の変換で前後何の関連性もない変換をします．これが一番の理由ですが，ATOK Passportで複数のクライアント間のユーザー辞書のシンクロも，失ってみるとかなり大きな存在であったと感じます．

あと，多少の誤入力を自動的に修正してくれるのも，やはり失うとその機能のありがたさを感じます．

だいたいそのくらいでしょうか．もちろん，Google日本語入力でも，手動でユーザー辞書の同期（具体的にはユーザー辞書を書き出してクラウドにおいて他のマシンでダウンロードして辞書ツールでマージする）はできますが，これを自動的に毎日やってくれるのはそれだけでも価値があります．

今回もベーシックプランとしました．今後試しにプレミアムにしてみる可能性は排除しないことにします．

Workstation．
これは当初から解っていたことでもありますが．