横断歩道手前の一時停止は善意でなく義務
firewalldを動かして，Avahi (mdns)を機能させる方法については，ネット検索するとすぐ見つかったので，firewalldを動かしたままにすることにします．
上記ページからの引用:
firewall-cmd --add-service=mdns --permanent firewall-cmd --reload
元記事は，CentOSのケースですが，Manjaro ARMでも同じでいけました．BLOG主さん，ありがとうございます．
Avahiなんて，Zeroconfなんですから，インストールして何の設定もしないでも機能するはずですが，Manjaro ARMだけどうしても機能してくれませんでした．
昨日12022年7月10日の段階で，
systemctl restart avahi-deamon
としてから，ほんの短い間2たぶん，1〜2分間．だけ，他の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)を常時見ることができるようにして，モニターとして活用することです．
これは確実です．ネットの複数の情報で裏が取れます1 “debian vlc disables 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です2ManjaroもDebianもSlackwareもKDE Plasma Desktopにしているので，使い勝手は共通で便利です．．VLCをパッケージマネージャー3pacmanだったり，pamacだったり😓でインストールして起動すると，ストリーミング画像を問題なく見ることができます．ただし，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は無理と判断しました．
このあといろいろ勘違いなどに基づく遠回りがありましたが，現在42022年7月9日(土)現在．の認識では，Manjaro ARM xfceのRPi4用のインストールイメージをSDカードに焼いて，RPi3(+)で起動してセッティングができます5インストールイメージで起動すると，途中で左上にカーソルが表示され，最初は点滅しますが，それがつきっぱなしになって数分間何の変化もありません．ここで，「RPi4用のインストールイメージではRPi3(+)は起動しない」と判断したのかもしれません．．
インストール後，Wi-Fiの設定をし，sudo pacman -Syuを実行してシステムをup-to-dateにしてから，VLCをインストールします．xfceには慣れてないので，GUIからインストーラーを見つけるのがめんどうで，コンソールから， pamac-manager &で起動しました．VLCで検索すると簡単に見つかります．
インストーラーは，たくさんの機能拡張について，どれを使うか聞いてきますが，どれがrtspに関係あるか解らないので全部選択しました6ただし，なんとかintelなんとかを選択するとエラーになってしまうので，それだけ外しました．．
これでインストール完了を待つのはかなり時間がかかるので，たいていほったらかしますが，少し時間が経ってから見ると，画面が消えていて手も足も出ません．
ただし，システムは活きているので，事前に調べておいたIPアドレスに他のマシンからsshでつなぎます7残念ながら，Manjaro ARMのAvahi / Zero-conf / Bonjourが機能しない問題は解決できていません（後に解決しました）．．
リブートしても画面は復活しないので，topコマンドでpamac8pamac-managerやpamac-daemon．がおとなしくなっていることを確認して，poweroffコマンドを実行してしばらくしてから電源を切り，また投入します．
この画面が消えるのは，チップの温度上昇によるものか，スクリーンロックの不具合によるのか現時点では解りませんが，たぶん前者だと思います．
RPi3(+)で，Manjaro ARM xfceを起動し，ログインすると主記憶1GBに対して，zramが1.3GBデフォルトで設定されていて，ここはいじる必要はありません．
デスクトップが表示されて落ち着いた時点で，CPUの温度はRPi3+で80℃弱，RPi3では80℃を少し越えています．
ということで，動作限界温度85℃までほとんどマージンがありません．
それでもRPi3+では，ぎりぎり85℃すれすれでVLCによるストリーミング画像表示ができます．CPUの負荷は200%を越えています．VLCはよくできています．
一方のRPi3では，VLCでストリーミング画像の表示を開始すると，しばしば画面が黒一色の何も表示しない状態になります．85℃を超えているのだと思います9gkrellmも見えないので，温度が解りません．．
RPi3もRPi3+もCPUなどのチップにフィンは付けてありますが，自然空冷でやっています．強制空冷しないと安定動作は無理だと思います．
Aliexpressあたりで，安い強制空冷のケースを探してみることにします．
Postfixを試すシリーズですが， “Postfixを試す (7) Avahiのbuildで難航” で更新が止まっているのに今気がつきました．
結局，Postfixをインストールしようと考えていたサーバーではMail Transfer Agent (MTA)は動かさないことに方針変更しました．Dovecotでサーバー内でやりとりされたメールだけ見てます．ほとんどは，というか全てLogWatchの様なシステムからAdminに宛てたメールですが．
とくに目標があるわけ1このPostfixを動かそうか検討していたサーバーに関しては，例外的に「使命」がありました😓でなく，個人の興味のままやっているので，つまみ食い，食い散らかしプロジェクトだらけです😓
今回の，もともと監視カメラの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でもだめです1md5sumでも同様のエラーが出ます．．
心配になってそのディスクにあるファイルを調べてみると，ここ1年以内に作ったqcow2以外のqcow2が皆同じエラーを出します．
最初はSSDの問題か，マザーボードのインターフェースの問題か，あるいはSSDとマザーボードの相性の問題か，などと考え，問題のSSDをUSBエンクロージャーに入れて，Raspberry Pi 4 Model B (RPi4)につないでcpやrsyncを試しましたが，同じエラーが出ます．
ということで，ここ1年より前に作った，まあ，知的資産のqcow2は全滅のようです．ほとんどここ数年触っていないファイルで，今回の電源断の時もリードオンリーでさえ開いていないので，電源断が問題とは思えません．
まあ，古い仮想マシンの仮想ディスクなんか，滅多に役に立つことはないので，実害はないのですが，長年熟成してきたのに寂しい気はします．