旧サイトで長らく使用していたwidgetの一つ,”Client IP Detector plugin” ですが,現在のWordPressに入れると,WordPress自体が動作しなくなります.困ったものです.
WordPressのディレクトリー内の “wp-content” 内の “plugins” にプラグインに対応したディレクトリーがありますから,そのディレクトリーごと削除すれば復旧します.
気に入っていたwidgetだっただけに残念です.
横断歩道手前の一時停止は善意でなく義務
旧サイトで長らく使用していたwidgetの一つ,”Client IP Detector plugin” ですが,現在のWordPressに入れると,WordPress自体が動作しなくなります.困ったものです.
WordPressのディレクトリー内の “wp-content” 内の “plugins” にプラグインに対応したディレクトリーがありますから,そのディレクトリーごと削除すれば復旧します.
気に入っていたwidgetだっただけに残念です.
Raspberry Pi 4 Model B RAM 4GBでまる4日ほど運用しました.定量的なデータは何もありませんが,LAN内のクライアント1からのアクセスでは,レスポンスがSlackware ARM 32bit時よりも少し改善された感じはしました.
ただし,写真のupload時の処理時間に大差はないです2.
今回は,同じRaspberry Pi 4 Model Bですが,RAM 8GBのものに置き換えました.RAM 4GBだと定常的な運転状態でswap (ZRAM)が500MB前後になります3.8GB RAMではswapが実質的にゼロなので,差は出ると思います.

このRedis Object Cacheの反応時間のグラフの中央 (16:35) あたりの大きなピーク(90 ms)はハードウェア交換直後に複数のdaemonが起動したため反応時間が大きくなったと推測できます.このピークの前がRaspberry Pi 4 Model B RAM 4GB,後が同8GBです.反応時間の平均的な値は小さくなっているように見えます.
この状態でまたしばらく運用してからRaspberry Pi 5に戻します.
プチフリーズというか,Core Spotlight daemonとPagesが連携してMetadataフォルダーを肥大化させる件について,今回Geminiに聞いてみました.
そうしたら,もう1人役者がいるそうで,それはiCloudです.iCloudがPagesのファイルの編集履歴を保存することとCore Spotlight daemonの連携にバグがあって無限にインデックスを作るようです.
iCloudにApple製アプリのファイルを保存するのは具合が良いのですが,この際他の場所に置いてみることにしました.
問題になっているM4 Mac miniのローカルSSDにおいても良いのですが,Google Driveに置いた方が他のMacから編集するのに楽なのでそうしました.
まだ数時間しか経っていないので,Metadataフォルダー内のCore Spotlightのフォルサイズは130MBと常識的な範囲内です.
前回のぬか喜びを反省して,1週間くらいはこのままで運用しようと思います.
Raspberry Pi 4 (RPi4)で運用し始めてまる2日経過しましたが,問題は特にないです.WordPressの反応もSlackware ARM (32bit)で運用していたときより速い感じがします.
Fail2Banも着実に排除するIPアドレスを増やしていってます.
また,GUIがそれなりに動くのはいいです.Firefoxが使えるので,記事を書いたり修正するのも楽です.
Slackware ARM (32bit)でもKDEが動くのですが,ちゃんと動くWebブラウザーがないのが残念なところでした.KDE自体も重かったです.
その点Raspberry Pi OSの標準であるPIXELは軽量でいいです.
RAMは4GBでちょうどいい感じです.しばらくLAN内で続けて動かしている旧サーバーはRAM 8GBで,これももったいないのでいずれ入れ替えようと思います.
以前経験したのに忘れてしまっていました.
サーバーをSlackware ARM 15.0からRaspberry Pi OS 13.3に切り替え,古いサーバーのデータなどを整理していたら,総容量が200GB程度まで減りました.
今まで1TBのSSDをつないでいましたが,半端な容量で使い道のない250GBのSSDがありこれに引っ越すことにしました.1TB SSDも空きます.
作業はManjaro AMD64 (x86_64)で行います.fdiskでGPTのパーティションを切り,mkfsでブート用のvfatとルートのext4をフォーマットします.
これが落とし穴で,Manjaroでフォーマットしたext4はSlackware 15.0では認識されないのです.
2回,コピーしてブートしてくれないので,インターフェースが悪いのかSSD自体が悪いのかなど悩みましたが,ManjaroでフォーマットしたボリュームはSlackwareでは読めないことを思い出しました.
このBLOGにもそれに関する記事があるはずですが今回見つけられませんでした😓
Geminiに聞いてみたら,古いKernelでは最新のmkfs.ext4のデフォルトでフォーマットしたボリュームはtoo newでマウントできないんだそうです.
回避策としては,
mkfs.ext4 -O ^orphan_file,^metadata_csum_seed /dev/sdXN
とします.あるいはSlackware上でフォーマットすればよいのです.
しかし,このような後方互換性のない新機能というのもちょっと困ったもんです.名前をext5にしてくれていればまだ分かりやすいものを.