横断歩道での一時停止は善意ではなく義務 (Powered by WordPress)
firewalldを動かして，Avahi (mdns)を機能させる方法については，ネット検索するとすぐ見つかったので，firewalldを動かしたままにすることにします．
上記ページからの引用:
firewall-cmd --add-service=mdns --permanent firewall-cmd --reload
元記事は，CentOSのケースですが，Manjaro ARMでも同じでいけました．BLOG主さん，ありがとうございます．
Avahiなんて，Zeroconfなんですから，インストールして何の設定もしないでも機能するはずですが，Manjaro ARMだけどうしても機能してくれませんでした．
systemctl restart avahi-deamon
としてから，ほんの短い間だけ，他のAvahi / Zeroconf / Bonjourが機能しているマシンからssh xxxx.localで，接続できましたが，時間が経つと，
ssh: Could not resolve hostname xxxx.local: Name or service not known
になってしまう，というところまでわかりました．
この結果を元に，いろいろネット検索しましたが，解決に結びつく情報を見つけることができませんでした．
先程，ふと思いついて，Avahiが問題なく機能しているManjaro x86_64と，問題のManjaro ARMとで，
systemctl status
を実行して，動いているデーモン類を比較したところ，Avahiが機能しないManjaro ARMの方だけ，firewalldなるデーモンが動いていました．
適切に，設定してやればいいのでしょうが，x86_64では動いていないので，「不要」と判断して，
systemctl stop firewalld systemctl disable firewalld
を実行したところ，めでたくAvahiが機能するようになりました．
なんか，これまでの取り組みに大きな見落としや大きな勘違いがあったようなので，もう一度最初からやります．
とはいえ，今まで得た知見で有効なものは利用します．
目標は，死蔵しているRaspberry Pi 3 Model BおよびB+(RPi3, RPi3+)で，監視カメラからのストリーミング映像(rtsp)を常時見ることができるようにして，モニターとして活用することです．
これは確実です．ネットの複数の情報で裏が取れますし，複数の実機と仮想マシン(x86_64, ARM)で試して全部同じ結果でした．
もし，Raspberry Pi OS(RPOS)のVLCがrtsp視聴を不可としていなければ，ずいぶん楽だったと思います．
Manjaro x86_64のVLCでは問題なくrtsp視聴可能です．古いCore i7のデスクトップ機で， “top” で見ると，CPUの占有率は画面のサイズを1/4からフルスクリーンに変えても，2%程度です．これは，Mac mini (2018 Core i7 6core)では，5〜9%です．
少し前から，RPi4 (RAM 4GB)でManjaro ARMを評価してます😓 デスクトップはお気に入りのKDE Plasma Desktopです．VLCをパッケージマネージャーでインストールして起動すると，ストリーミング画像を問題なく見ることができます．ただし，CPUの占有率は60〜90%です．
RPi4は，RPi3(+)に比べて3倍くらいパフォーマンスが良いと記憶していますから，RPi3(+)で動かすと占有率が200%を越える可能性があります．そんな条件で動作可能なのかどうなのかです．
後(2022/08/11)の注: RPi3(+) RAM 1GBで，KDE Plasma Desktopの動作は可能です．
手持ちのRPi3, RPi3+はどちらも主記憶が1GB で，たぶんそれぞれのシリーズで最大と思います．しかしこれではKDE Plasma Desktopは無理です．
これは，あとで再現できないので，夢を見ていたのかもしれませんが😓，RPi4でルートにしているSSDに，RPi3+のRPOSのkernel モジュールをディレクトリーごとコピーして，そのRPOSの/boot/cmdline.txtを編集してSSDのManjaroパーティションをルートに指定してRPi3+の起動に成功したことがあります．結局，ログインしてもデスクトップがいつまでもちゃんと表示されず，KDE Plasma Desktopは無理と判断しました．
このあといろいろ勘違いなどに基づく遠回りがありましたが，現在の認識では，Manjaro ARM xfceのRPi4用のインストールイメージをSDカードに焼いて，RPi3(+)で起動してセッティングができます．
インストール後，Wi-Fiの設定をし，sudo pacman -Syuを実行してシステムをup-to-dateにしてから，VLCをインストールします．xfceには慣れてないので，GUIからインストーラーを見つけるのがめんどうで，コンソールから， pamac-manager &で起動しました．VLCで検索すると簡単に見つかります．
インストーラーは，たくさんの機能拡張について，どれを使うか聞いてきますが，どれがrtspに関係あるか解らないので全部選択しました．
これでインストール完了を待つのはかなり時間がかかるので，たいていほったらかしますが，少し時間が経ってから見ると，画面が消えていて手も足も出ません．
ただし，システムは活きているので，事前に調べておいたIPアドレスに他のマシンからsshでつなぎます．
リブートしても画面は復活しないので，topコマンドでpamacがおとなしくなっていることを確認して，poweroffコマンドを実行してしばらくしてから電源を切り，また投入します．
この画面が消えるのは，チップの温度上昇によるものか，スクリーンロックの不具合によるのか現時点では解りませんが，たぶん前者だと思います．
RPi3(+)で，Manjaro ARM xfceを起動し，ログインすると主記憶1GBに対して，zramが1.3GBデフォルトで設定されていて，ここはいじる必要はありません．
デスクトップが表示されて落ち着いた時点で，CPUの温度はRPi3+で80℃弱，RPi3では80℃を少し越えています．
ということで，動作限界温度85℃までほとんどマージンがありません．
それでもRPi3+では，ぎりぎり85℃すれすれでVLCによるストリーミング画像表示ができます．CPUの負荷は200%を越えています．VLCはよくできています．
一方のRPi3では，VLCでストリーミング画像の表示を開始すると，しばしば画面が黒一色の何も表示しない状態になります．85℃を超えているのだと思います．
RPi3もRPi3+もCPUなどのチップにフィンは付けてありますが，自然空冷でやっています．強制空冷しないと安定動作は無理だと思います．
Aliexpressあたりで，安い強制空冷のケースを探してみることにします．
Postfixを試すシリーズですが， “Postfixを試す (7) Avahiのbuildで難航” で更新が止まっているのに今気がつきました．
結局，Postfixをインストールしようと考えていたサーバーではMail Transfer Agent (MTA)は動かさないことに方針変更しました．Dovecotでサーバー内でやりとりされたメールだけ見てます．ほとんどは，というか全てLogWatchの様なシステムからAdminに宛てたメールですが．
とくに目標があるわけでなく，個人の興味のままやっているので，つまみ食い，食い散らかしプロジェクトだらけです😓
今回の，もともと監視カメラのrtspの映像を転がっているRaspberry Pi 3 Model Bで見ようプロジェクトも，VLC playerがDebianでは機能制限されていることを知り，他のdistroのVLC playerをいろいろ試したいがそれなら仮想マシンが楽ではないかと思い試し始めたら， 仮想マシンの調子がおかしい，そもそもSSDが故障しているのではないか，となって，コピーできる仮想マシンを別ドライブに移した上で，現在SSDの動作を検証中です．
Real Time Streaming Protocol (rtsp)をRaspberry Pi 3 Model B (RPi3)でどう見るかの続きです．
残念ながらManjaroは，RPi3では動かないようです．そこで今度は，Ubuntuを試すことにしました．まずはx86_64 (AMD64)で試してからの方が早いだろうと思い，第2 workstation (WS2)の仮想マシンのUbuntuを久しぶりに動かしてみました．いつupgradeしたか全く記憶にありませんでしたが，LTS 20.04になっていました．せっかくだからこの際，最新の22.04にしようと，ネット検索してやり方を探しながら試みました．で，最後のまじない，
do-release-upgrade
を実行していたところ，突然電源が切れました．すぐに何が起こったか解りました．もともと電源コードが緩いのです．ACスイッチをON/OFFすると電源コードにどうしても触れて，しばらく繰り返すと，プラグが外れてしまいます．
それが解っているので，電源ON/OFFの際プラグを押し込む様にしていますが，しばらく忘れていたところ，一番抜けてはいけないタイミングで抜けてしまいました😓
まあ，最近はjournaling file systemなので，途中でズバッと電源を切ったところで，ファイルシステム(FS)が壊れることは滅多にありません．しかし，do-release-upgradeの途中なのでdpkgデータベースがかなり深刻にダメージを受けているに違いありません．
実際，ネットの情報を調べてaptなんとかかんとかしても，全然前進しません．こういうときのために，バックアップを取ってあります．
しかし，そのバックアップのディスクイメージをコピーすると， “input/output error” とかなんとか言ってコピーできません．rsyncでもcpでもだめです．
心配になってそのディスクにあるファイルを調べてみると，ここ1年以内に作ったqcow2以外のqcow2が皆同じエラーを出します．
最初はSSDの問題か，マザーボードのインターフェースの問題か，あるいはSSDとマザーボードの相性の問題か，などと考え，問題のSSDをUSBエンクロージャーに入れて，Raspberry Pi 4 Model B (RPi4)につないでcpやrsyncを試しましたが，同じエラーが出ます．
ということで，ここ1年より前に作った，まあ，知的資産のqcow2は全滅のようです．ほとんどここ数年触っていないファイルで，今回の電源断の時もリードオンリーでさえ開いていないので，電源断が問題とは思えません．
まあ，古い仮想マシンの仮想ディスクなんか，滅多に役に立つことはないので，実害はないのですが，長年熟成してきたのに寂しい気はします．