バックアップの削除でサーバーが無応答に

現在サーバーのバックアップは,バックアップの際にマウントする2TBのHDDに,前回からの差分をバックアップする形にしています.

rsyncでバックアップしています.今日の日付からなるディレクトリーをバックアップのボリュームに作り,ひとつ前の日付のディレクトリーを--link-destオプションで指定してサーバー内の全部(ただし,バックアップのボリュームのマウントボインや/tmp, /dev等は除く)をコピーすることで,変更がないファイルはハードリンク,変更があったファイルは新しいファイルをコピーするようなことを勝手にやってくれます.

rsyncは優秀で他のサービスに影響ありません.だいたい15分くらいで終わります.ただし,毎日毎日バックアップを続けると,だんだんハードリンクが長くなるせいか,バックアップに要する時間が長くなってきます.30分,1時間,ついには1時間越えと.

そこでときどき古いバックアップを削除します.手作業です.削除は普通にrmコマンドに-rオプションを付ければよいです.ただこれがなかなか重い作業で,rm自体はメモリーをほとんど食わず,SWAP領域が増えることもないのですが,kswapd0デーモンがかなりCPUサイクルを食います.何が起こっているかよく解らないのですが,ルートドライブもこのバックアップドライブもUSB接続だというのが良くないのではないかと今は推測しています.

昨日もずっとhttpdやその他のデーモンが動かなくなっていたのを知っていましたが,rmコマンドを途中でやめるわけにも行かず,一晩そのままにしておきました.

rmコマンドが終了しても,デーモン類はスタックしたまま自動的には復活しないので今朝システムごとリブートしました.

今後はバックアップの削除は他のWSにつないで行うことにします.

ThunderbirdがDovecotに繋がらなくなった件 (解決済み)

自前のサーバーで動くLet’s Encryptの証明書をupdateしてからどうもクライアントであるThunderbirdの挙動がおかしくなりました.

TLSのimap (=imaps)でつないでいます.ログインはできて新着メールは読めるのだけれど読んだメールをサブディレクトリーに移そうとしてもうまく操作ができません.

Appleの iOSやmacOSの “Mail” では正常に動作します.

サーバーのログを見ると,

というのがあり,たぶんこれだと思います.ネット検索した所,どうもDovecotのSSL/TLS設定が良くなかったようです.これまで,/etc/dovecot/conf.d/10-ssl.confのssl_certの設定は,

ssl_cert = </etc/letsencrypt/live/FQDN/cert.pem

としていました.これでこれまでAppleの “Mail” (iOS, macOS)もThunderbirdもつながっていましたが,

ssl_cert = </etc/letsencrypt/live/FQDN/fullchain.pem

としないといけないようです😅

これで,サーバーのDovecotのログにエラーは出ず,Thunderbirdも正常にサブフォルダーをアクセスできるようになったようではあります.

しかし,違うマシンのThunderbirdでアクセスすると見えないサブフォルダーが存在するなど今いち動作の信頼に欠けます.

Distroによっては番号が違う場合があります.

サーバー不安定 (3) ひとまず安定か

昨日から何度かリブートはかけましたが,24時間以上システムが無応答になったり,おかしな挙動をすることもなく安定して動いているようで,ひとまず安心です.

故障した可能性が大きいRaspberry Pi 4 Model B (RPi4) RAM 8GBの代わりをどうするか.先々を考えると少し奮発してRPi5 8GBを買うのが良さそうですが,まだRPi5で動くSlackware Aarch64の正式リリースはなく “Current” で使い続けるのは無理なので迷うところです.

Slackware ARM (32bit)のRPi5 hackは何故か存在しないのです.

このままRPi4 4GBでしばらく行ってみます.

サーバー不安定 (2) 本体かも

どうも,サーバーの不安定の原因は,USBまわりというところだけは正解のようですが,USB接続のSSDでもUSB HUBでもなさそうです.

本体を予備のRaspberry Pi 4 Model B (RPi4)にしました.違いは本来のサーバーはRAM 8GBのところ,予備機は4GBというところです.

予備機: Raspberry Pi 4 Model B RAM 4GB

SSDのまるまるコピーなどといった負荷をかけながら動かしていて,起動から5時間経過しましたが,今のところ正常のようです.

また8GBの方もSDカードを入れてVLCで監視カメラのモニターをさせています.USBは使わない状態です.こちらも同じく5時間安定して動いています.

ということで,RPi4のハードのUSBまわりの故障のように思います.

ちなみに,GUIなしのサーバー用途でRAMは4GBもあれば十分かと思いましたが,そうでもなくて,rsyncによるディスクのまるまるコピーのようなバッファを多く使うタスクを実行していると,kswapd0が大汗をかく場面が多く,その場合zramといえどもhttpdのレスポンスはかなり悪くなります.

RPi4 8GBとなるとRPi5に価格が近くなるので迷います.

DOSBox-XでLog200

DOS用LogソフトLog200をWindowsのDOS窓以外で動かす取り組みですが,Slackware64 (AMD64)のDOSEMUのもとで,Log200を動かして,Slackware ARM (32bit)のサーバー上にあるデータファイルはNFSでアクセスしよう,ということにしました.DOSEMUはmacOS上で動くVMWare Fusionで動くSlackware64でも動きますし,そこからNFSでサーバーのディレクトリーをマウントすることもできますから,仮想マシンと実マシンのいくつかの環境からLog200を実用的に使えます

いちおうこの状態を結論としていました.

ところが先日,親切な通りすがりのかたが,DOSBox-XのDOS/VモートでLog200が動く可能性が高いとアドバイスしてくださいました.

さっそくDOSBox-Xがインストール済みなmacOS (x86_64 Sonoma 14.5, x86_64 Ventura 13.8.7)で試したところ,あっさり動きました.通りすがりのかたに教えていただいた通り,基本的に設定ファイルである “dosbox-x.conf” に,

[dosv]
dosv=jp

と書くだけで自前でDOSを用意する必要さえもありません.

macOS Ventura (x86_64 13.8.7)上で動くDOSBox-Xで動くLog200 (DOS版)

以前調べたところではDOSB0x-Xは,Debian (Raspberry Pi OS)やManjaroでは公式チャンネルからの配布はありません.代わりにFlatpakというパッケージマネージャーでインストールすることになっていて,今回あらためてインストールしたところ,日本語DOS/Vモードがちゃんと動き,Log200も問題なく動きました.

Raspberry Pi OSにインストールしたFlatpakで動くDOSBox-Xで動くLog200

Flatpakでうまく行った環境は,

  • Manjaro AMD64
  • Raspberry Pi OS (64bit)

です.あっさり書いちゃましたが,非x86のRaspberry Pi OS(Raspberry Pi 5 Model B 8GB RAM)でも簡単に,しかも実用上問題ない速度で動きました.

Raspberry Pi OSで動きますから,Debian AMD64でも間違いなく動くでしょう.

最終目標である,Slackware ARM (32bit)ですが,もちろん公式配布パッケージにDOSBox-Xは含まれていませんが,SlackBuildsにはあるので,sbopkgでインストール可能な可能性があります.一方SlackBuildsにはFlatpakもあります.

他にFlatpakで動かすアプリがいくつかあれば先にFlatpakを試す価値はありますが,いまのところDOSBox-Xだけですから,先にDOSBox-Xをsbopkgでbuildするほうがいいだろうと判断してそうしました.

で,buildできて動きました

Slarckware ARM (32bit) 15.0にsbopkgでインストールしたDOSBox-Xで動くLog200 DOS版

いよいよSlackware ARM64 15.1のリリースが待ち遠しいです.

仕立ててはいませんが,Manjaro AMD64をホストにしてSlackware64のゲストからも同様にLog200は動かせます.
MacPortsによる.
buildには少々時間がかかりますが.