OSを変えたら治ったなどという絶望的な記事を見つけて,諦めてしまっていましたが,ブラウザによらないということで,これはなんかブラウザではないところに原因がありそうと,もう少し検索を進めたところ解決しました.
なんと,システム設定のアクセシビリティーにあるスクリーンリーダーONがいけないとのことです.
- [SOLVED] Firefox scrolling to the bottom of the webpage (ArchLinux Forums)
そんなものONにした覚えは全く無いです.
横断歩道での一時停止は善意ではなく義務 (Powered by WordPress)
OSを変えたら治ったなどという絶望的な記事を見つけて,諦めてしまっていましたが,ブラウザによらないということで,これはなんかブラウザではないところに原因がありそうと,もう少し検索を進めたところ解決しました.
なんと,システム設定のアクセシビリティーにあるスクリーンリーダーONがいけないとのことです.
そんなものONにした覚えは全く無いです.
注: 解決しました → Firefoxが勝手に最後までスクロールする(解決)
かなり前からなのですが,サブworkstation(サブWS)のサブOSであるDebianでFirefoxを使ってweb pageを開くと,開くたびにそのページの最後まで勝手にスクロールしていって,ページの読み込みとそのスクロールが完了するまで手も足も出ない状態となります.
とはいえ,いったん最後までスクロールすればあとはフツーに使えるし,サブWSのサブOSではそんなに生産性が問題になる作業はしないので,不問に付してきました(時々はネット検索で解決策を探りましたが).
今回,Debianの実マシン環境で動くKVMが必要となり,そこでFirefoxを開いて,調べたり,wikiに書き込んだりして作業を進めようとしましたが,そういう生産的😥な仕事をするには,この勝手なスクロールは著しく作業効率を落とします.というか,やる気が失せます.
そこで,真剣に検索をしてみました.日本語で検索してもだめなので,英語で検索することにして,まず「勝手に」を英語でなんていうかから調べました.それで,
Debian Firefox scrolls arbitrarily to the bottom
てな感じで検索したら,ズバリのものが見つかりました.
で,この質問者は,違うOSをインストールして解決したとあります.つまり,本当の意味での解決策はないのです😥
サブWSのメインOSであるManjaroではこのようなトラブルはもともと発生してませんから,Manjaroでやれよなってことです.
ふと,これはDebianにバンドルされているFiref0x-ESRの問題で,本家からダウンロードしたものは大丈夫なのではと思い,試してみましたが,同じでした😥
また,ふと思いついて,Chromiumをイントールして,試してみました.同じです😥 どうしたものか,最後までスクロールしていき,落ち着くまで操作できません.
この2つのテストにより,ブラウザーが悪いのではなく,GUI・デスクトップに何らかの問題があるといえそうです.
DebianのサブOSと同じKDE Plasma Desktopを使っているメインOSのManjaroではなんの問題も起きないんだけどなあ😥
LogWatchの7.6をインストールしたのですが,cron.dailyで飛ばしているlogwatchからメールが来ません.
ちゃんと,パッケージ内にある “README” の通りにしたのですが,結論的にはそれが間違いでした.
“README” には,
ln -s /usr/share/logwatch/scripts/logwatch.pl /etc/cron.daily/0logwatch
とするように書いてありその通りにしていましたが,これだと/etc/logwatch/conf/logwatch.conf
は空なので,/usr/share/logwatch/default.conf
のまま,logwatch.plが実行されます.それではOutputはstdoutになってますから,いくら待ってもメールは来ません.
LogWatch 7.4.xでちゃんとメールが来ていた旧システムの設定を調べたところ,/etc/cron.daily/0logwatch
はsymlinkではなくて,"--output=mail"
というオプションを付けてlogwatch.plを実行するscriptになってます.
このスクリプトは配布パッケージのscheduler内のlogwatch.cronです.特に “README” 内では何も触れてないです😓
もちろん,/etc/logwatch/conf/logwatch.conf
に,
output=mail
と書く方法もありますが,これだとテストなどで手動でlogwatch(.pl)を動かす度にメールが送られて,ややスマートさに欠けます.
とはいえ,LogWatchからちゃんとメールが来るようになったら手動でlogwatchを起動する必要性も低いので,上記の設定をした上で,手で起動する時は,
--output=stdout
というオプションを付けてlogwatchを動かせば良いだけかもしれません.
そういえば,SlackwareARM 15.0のサーバーにまだLogWatchをインストールしていないことを思い出して,インストールすることにしました.前のOS (SlackwareARM 14.2) の時には,LogWatch 7.4.3 をインストールしていましたが,現在は7.6が最新版です.
手でインストールしてもいいのですが,SlackBuildsに用意されているので,
sbopkg -i logwatch
でインストールしてみました.試しに,/etc/cron.daily/0logwatch
を走らせてみると,
/bin/sh: warning: shell level (1000) too high, resetting to 1
というメッセージが繰り返し出て,しまいにはsshdがこけてしまったのか,sshによる接続が切られてしまいました.
上記メッセージは,繰り返しshが呼ばれた時に起こるそうです.なんか,SlackBuilds提供のLogWatchインストールのためのスクリプトか,あるいは起動のためのスクリプトがバグっているようです.
そこで,removepkg
してから,手動でインストールをしました.インストールの仕方はソースパッケージの “README” に書いてあります.
手動で動かしたところ,コンソールにログのサマリーが出て,正常終了しました.しばらくcronで飛ばして様子を見ます.
Postfixを試すのにAvahiが要るのか,という疑問もあるかと思いますが,筆者のLAN内ではAvahiを有効利用しているので,テストの準備などのいろんな手続きをスムーズにするためインストールすることにしました.
Slackware (64, ARM) 15.0用としてSlackBuildsにzeroconfのサーバーであるAvahi,クライアントであるnss-mdns,そしてAvahiに必要なライブラリーlibdaemonが用意されています.したがって,libdaemonからの順番で,sbopkg -iすれば,インストール完了します.実際,SlackwareARM 15.0のとあるマシンでは,そのようにして他のマシンを参照するのも,他から参照されるのもうまく機能しています.
ところがどっこい,Postfixのテスト用に仕立てたSlackware 15.0 (32bit)の仮想マシンでは,Avahiのbuildができません.gtk+2のバージョンが必要条件(>=2.14.0)を満たしていないとconfigureスクリプトが文句を言いますが,pkgtoolで確認するとちゃんと条件を満たしています(2.24.33).エラーメッセージは的が外れているけど,なにか確かにエラーがあるに違いないです(よくあることです😥).
うまくいったSlackwareARMと失敗したSlackware (32bit)の違いは,もちろんアーキテクチャーや,実マシン・仮想マシンの違いがありますがそれらは別にして,X, XAP, KDEをインストールしていないことです.リモートで運用・管理するのが前提なので,そもそもGUIは要りませんので,省略することによってシステムの容量を減らすことができると考えました.
しかし,これがどうもいけないようです.そもそもAvahiにGUIは関係ないと思うのですが,なんか必要なライブラリーがGUIのライブラリーと依存関係にあるとかないとかいうことでしょうか.知らんけど😥
必要最低限のライブラリーを見つけ出してインストールするというのがGUIをインストールしなかった初期の方針に沿う方法でしょうけど,時間が無駄にかかりますので,ここは諦めて,XとXAPはインストールすることにします(いくらなんでもKDEは要らんでしょう😥).
ここも,ここまでいじってきたシステムにXとXAPを追加してインストールすればいいんですが,完成したときにクリーンインストールからの最小手順だったという形にしたいので,また箱庭を消してゼロからやります.