横断歩道での一時停止は善意ではなく義務 (Powered by WordPress)
Manjaro KDE Plasma Desktop版をRaspberry Pi 3 (RPi3)にインストールして，Real Time Streaming Protocol (RTSP) の映像を見るというプロジェクトでは，いろいろ試行錯誤の結果，ほぼ当初の目標を達成することができました．
余勢を駆って，KDE Plasma Desktop版よりも軽いであろうxfce版でも同じことをやってみたところ，あっさりできてしまいました．
ただし，KDE Plasma Desktop版で相性の問題で，ソース切り替えの後に画面が復活しないモニターは同じ問題が生じます．
最終的なまとめを書いた時点では，「使い物にならない」でしたが，その後ほとんど問題なく，Raspberry Pi 3 Model B (RPi3)でも，Raspberry Pi 3 Model B+ (RPi3+)でも，電源をつなぐと問題なくフルスクリーンでVLCが動いて，RTSPの画像を表示するようになりました．一番つなぎやすいWi-Fiのプライオリティーを上げてから，Wi-Fiの接続が遅れてVLCがエラー吐くこともほとんどなくなりました．
それで最終評価も，「使い物にならない」から，「若干問題があるが使える」に格上げしました😓
「若干問題」としましたが2つです．一つ目は，Desktopの設定もVLCの設定も再三再四確認したのですが，スクリーンセーバーが働いて，数分から10〜20分の間に画面が黒くなってしまうことです．
二つ目は，見ているモニター側で入力を切り替えたり，その効かせないはずのスクリーンセーバーが効いたあと，マウスを動かそうが，キーボードをたたこうが，sshでつないで，VLCを終了して再起動しようが画面が復活することはなく，いったんpoweroffしてから，電源をつなぎ直して再起動するしかありません．
二つ目に関しては，どうもモニター側に問題がある，あるいはモニターとRPi3(+)との相性が存在するようで，特定のモニターで頻発します．ですから，選ぶ余地があれば，問題が発生しないモニターを使う事で，回避できます．
「若干」が「一つ」に絞られましたが，これは，xdotoolを使う事でなんとかなりそうです．3分くらいでポインターを少し動かします．難点はその都度制御用のツールバーが一瞬表示されることです．
ターミナルからスクリプトでxdotoolを動かすのは成功したので，自動で動くように仕込みたいと思います．
その後，xdotoolでマウスを擬似的に動かしてスクリーンセーバーの機能を回避する方法について調べていたら，xsetを使って，
xset -dpms ; xset s off
を実行するalternativeが見つかりました．試したところ今のところうまくいっています．ということは，KDEのセッティングがバグっているということでしょう．
これをLoginスクリプトとして登録すればいけそうです．
テスト完了しました．結論的には，「多少問題はあるけど使える」です．
固定ページに移行しました（2022/09/02）．
ここ数年解らなかった，httpdを動かしているとメモリーの空きがなくなり，swapが発生してシステムのレスポンスが悪くなる件ですが依然としてよく解りません．
RAM 4GB版のRaspberry Pi 4 Model B (RPi4)を起動すると，半日くらいで空きメモリーを使い切り，kswapd0が働きだし，zramが消費されはじめます．
ファイルやパーティションを使うswapをやめてzramにしたのは，httpdサーバーが主な仕事のこのマシンにしてみれば，対象療法にはなっている訳です．
一方，予備機としてRAM 8GB版のRPi4もあり，いろいろなテストの目的でときどき入れ替えて使用していますが，4GBのRPi4と比較すれば、起動直後の空きメモリーに4GBが加算される形になるので余裕があります．こちらは半日動かしたくらいでは5GB以上メモリーに空きがあります．
これが不思議なんですが，8GBで5GB以上余裕があるなら，4GBでも1GB余裕があっていいはずなんですがそうはならないのです．
しばらく4GBと8GBをとっかえひっかえしながら様子を見てみることにします．
export NSS_SDB_USE_CACHE=YESとしてhttpdを起動するexport TMPDIR=/dev/shmとしてhttpdを起動する
某サーバーはメモリーが4GBと8GBの主副のRaspberry Pi 4 Model B (RPi4)をときどき入れ替えて，運用しています．
4GBのほうでは気がつくとkswapd0が大汗かいてます．8GBではそういうことはありません．
httpdを再起動すると，いったんかなりのメモリーが解放されますが，また何時間か経つと，kswapd0が大汗かいてます．zramを使用しているので，ファイルやパーティションをswapのメディアにしているときよりは，レスポンスはいいですが，それでも，何かコマンドを打ち込んでも反応するのにちょっと時間遅れがあります．
ずっと原因がわかりませんでしたが，https接続でphpが動いてlibcurlが動くと，nssがslabを大量に使うのが原因のようですということらしいです，って聞いても何が何だか解りません😓
下記参考ページにあるように，ときどきslabを開放してやるのがひとつの解法のようですが，根本治療は，
export NSS_SDB_USE_CACHE=YES
もしくは，
export TMPDIR=/dev/shm
のどちらかを “どこか” で実行することのようです．当該サーバーの場合どこで実行すれば良いのか解らないので，しばらく試行錯誤します．