9,800円の古いMac miniに、もう一度仕事を。 ― Python の watchdog とsystemd で作る常駐監視〈第2回／全5回〉

はじめに

前回は、9,800円で購入した古い Mac mini に Debian 13 を導入し、自分専用の画像ライブラリへ作り替えた全体像をご紹介しました。

完成した仕組みでは、MacBookPro から共有フォルダへ画像を入れると、Mac mini がその到着を検知します。画像の情報はデータベースへ記録され、最後にはブラウザから検索できるようになります。

もっとも、最初からそこまでを作ろうとしたわけではありません。

今回の目標は、前回の最後に記したとおりです。

言葉にすれば、それほど複雑には見えませんが、ファイルが「見えた」ことと、安心して「受け取れる」ことは、同じではありませんでした。

✳︎この記事では、Linux のユーザー名を serveruser と表記します。実際に試す場合は、ご自身の環境で使用しているユーザー名へ読み替えてください。

画像を受け取る場所

MacBookPro と Mac mini の間でファイルを受け渡すため、Samba による共有フォルダを用意しています。

Samba とは、Linux 上のフォルダを、macOS や WindowsOS からネットワーク経由で利用できるようにする仕組みです。

今回、その共有領域の中にinboxというフォルダを設けました。

/home/serveruser/share/inbox

MacBookPro の Finder から見ると、普段使っているフォルダと大きな違いはありません。画像を選び、共有フォルダへコピーできます。

一方で、Mac mini 側から見れば、ここにはもう一つの役割があります。inbox は単なる保存場所ではなく、画像ライブラリの玄関で、画像がここへ届いたことを合図に、後の処理が始まります。

フォルダの変化を見守る watchdog

フォルダの監視には、Python の watchdog というライブラリを使いました。

watchdogは、ファイルの作成、変更、移動、削除といった変化を検知するための仕組みです。

名前だけを見ると、少し大げさに感じるかもしれません。実際に行うことは、誰かがファイルを置いたとき、その出来事を静かに受け取ることです。

まず、プログラムを置く場所を作ります。

mkdir -p /home/serveruser/apps/file-watcher
cd /home/serveruser/apps/file-watcher

続いて、このプログラム専用の Python 仮想環境を用意しました。

python3 -m venv venv

./venv/bin/pip install \
  watchdog \
  Pillow

仮想環境とは、Python本体へ直接手を加えず、プログラムごとに必要な追加機能を分けて管理する仕組みです。

今回のように、長く動かす小さなプログラムでは、後から何を追加したのかが分かることも大切です。

最初に作った監視処理は、ごく簡素なものでした。

from watchdog.events import (
    FileSystemEventHandler,
)
from watchdog.observers import Observer


WATCH_DIR = "/home/serveruser/share/inbox"


class InboxHandler(FileSystemEventHandler):
    def on_created(self, event):
        if event.is_directory:
            return

        print(
            "ファイルを検知:",
            event.src_path,
        )


observer = Observer()

observer.schedule(
    InboxHandler(),
    WATCH_DIR,
    recursive=True,
)

observer.start()

recursive = True は、inbox の直下だけでなく、その中にあるサブフォルダも監視する指定です。

この状態で MacBookPro から画像を一枚コピーすると、Mac mini 側へファイルの場所が表示されました。

まだ画像の内容は調べていません。データベースもありません。それでも、共有フォルダへ置いた画像にMac miniが応じたことには、小さな手応えがありました。

古い機械に、新しい仕事が生まれた最初の瞬間です。

検知した時点では、コピーが終わっていない

ここで、最初の問題が見つかりました。

watchdog がファイルの作成を知らせた時点では、必ずしもコピーが完了しているとは限りません。容量の大きな画像は、一瞬で現れるわけではありません。まずファイルが作られ、その中へ少しずつデータが書き込まれます。

つまり、監視プログラムからはファイルが見えていても、その内容はまだ届いている途中かもしれません。

この段階で画像を開けば、読み込みに失敗することがあります。ハッシュ値を計算しても、完成後とは異なる値になる可能性があります。

急いで処理を始めることは、かえって不確かな記録を残すことになります。

そこで、ファイルを検知しても、すぐには次の処理へ進まないようにしました。

変化が止まるまで待つ

コピーの完了を判断するため、ファイルの容量と更新時刻を一定間隔で確認します。

今回の設定は、次のとおりです。

STABLE_SECONDS = 3
CHECK_INTERVAL = 1
MAX_WAIT_SECONDS = 60

1秒ごとにファイルの状態を確認し、容量と更新時刻が3秒間変わらなければ、コピーが終わったものと判断します。

処理の考え方は、次のようになります。

def wait_until_stable(path):
    previous_signature = None
    stable_for = 0

    while True:
        stat = path.stat()

        signature = (
            stat.st_size,
            stat.st_mtime_ns,
        )

        if signature == previous_signature:
            stable_for += CHECK_INTERVAL
        else:
            previous_signature = signature
            stable_for = 0

        if stable_for >= STABLE_SECONDS:
            return stat

        time.sleep(CHECK_INTERVAL)

同じ状態が続いたことを確かめてから、ファイルを受け取ります。
3秒という時間に、特別な意味があるわけではありません。ネットワークや扱うファイルによって、適切な値は変わります。

今回は家庭内ネットワークで画像を転送することを前提に、短すぎず、待たせすぎない値として設定しました。

また、何らかの理由でファイルが完成しない場合に、プログラムが永遠に待ち続けないよう、最大待機時間も設けています。

ログには、次のような順序で記録を残します。

ファイル到着を検知、コピー完了待ち
ファイル準備完了

・届いたことを知る
・少し待つ
・変化が止まったことを確かめる

単純な手順ですが、この慎重さが後の処理を支えます。

ファイルの「作成」と「移動」を受け取る

MacBookPro から Samba 経由でファイルを置いた場合、常に同じ種類の通知が届くとは限りません。

新しいファイルとして作成されることもあれば、一時的な名前で作られた後、完成時に別の場所へ移動されることもあります。

そのため、作成だけでなく、移動の通知も受け取るようにしました。

class InboxHandler(FileSystemEventHandler):
    def __init__(self, processor):
        self.processor = processor

    def on_created(self, event):
        if not event.is_directory:
            self.processor.submit(
                event.src_path
            )

    def on_moved(self, event):
        if not event.is_directory:
            self.processor.submit(
                event.dest_path
            )

作成された場合は src_path を使い、移動された場合は移動先であるdest_path を使います。

Samba や Finder の内部動作をすべて意識しなくても、最終的に届いた場所を監視プログラムへ渡せるようになりました。

macOS が残す小さな管理ファイル

macOS から共有フォルダを利用すると、画像以外のファイルが作られることがあります。

代表的なものが、次のようなファイルです。

.DS_Store
._example.png
.smbdelete...

.DS_Storeは、Finderがフォルダの表示方法などを保存するためのファイルです。

._から始まるファイルには、macOS 固有の補助情報が含まれることがあります。.smbdelete から始まるものは、Samba がファイル操作の途中で使用することがあります。

いずれも、画像ライブラリへ登録する必要はありません。
そこで、名前が.で始まるファイルを監視対象から外しました。

def should_ignore(path):
    return path.name.startswith(".")

最初は.DS_Storeなどを個別に指定していました。
しかし、実際の運用では、想定していなかった一時ファイルが現れることがあります。今回の用途では、隠しファイル全体を除外するほうが、意図を明確に保てました。

同じファイルを重ねて処理しない

ファイル監視では、一つの画像について複数の通知を受け取ることがあります。

作成されたという通知の直後に、移動や変更の通知が届くこともあります。

通知が届くたびに同じファイルを処理すると、余計な読み込みが増えます。後でデータベースへ保存する段階では、重複登録の原因にもなりかねません。

そのため、処理待ちのファイルを pending という集合で管理しました。

def submit(self, path_string):
    path = Path(path_string)

    if should_ignore(path):
        return

    path_key = str(path)

    with self.lock:
        if path_key in self.pending:
            return

        self.pending.add(path_key)

    self.work_queue.put(path)

すでに待機中のファイルであれば、二度目の通知は受け流します。

処理が終わった後で、pendingから取り除きます。

ここで使っているlockは、複数の処理が同時に同じ集合を書き換えないようにするためのものです。

ごく短い処理ですが、「同じものを二度扱わない」という決まりを、プログラム側でも守らせます。

ターミナルを閉じても働くようにする

ここまでのプログラムは、ターミナル（文字でコマンドを入力し、コンピューターを操作するための画面）から直接起動すれば動きます。
しかし、ターミナルを閉じたり、Mac mini を再起動したりすると、監視も止まってしまいます。

日常的に使う仕組みであれば、その都度手作業で起動するのは現実的ではありません。

そこで、監視プログラムを systemd のサービスとして登録しました。
systemd とは、Linux 上でプログラムの起動、停止、自動再起動などを管理する仕組みです。

設定ファイルは、次の場所へ置きます。

/etc/systemd/system/file-watcher.service

内容は次のようにしました。

[Unit]
Description=File Watcher
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=serveruser
Group=serveruser
WorkingDirectory=/home/serveruser/apps/file-watcher
ExecStart=/home/serveruser/apps/file-watcher/venv/bin/python /home/serveruser/apps/file-watcher/watch_inbox.py
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
PrivateTmp=true
UMask=027

[Install]
WantedBy=multi-user.target

UserとGroup には、このプログラムを動かす利用者を指定します。
ExecStart には、仮想環境内の Pythonと、監視プログラムの場所を記します。

Restart = on -failure を指定すると、予期しない異常でプログラムが終了した場合、systemd が再起動を試みます。NoNewPrivileges = true は、動作中のプログラムが新たな特権を得ることを防ぐ設定です。

機能を動かすことだけでなく、与える権限を必要な範囲へとどめることも意識しました。

サービスを有効にする

設定を書いた後、systemd へ内容を読み込ませます。

sudo systemctl daemon-reload

続いて、サービスを有効化し、その場で起動します。

sudo systemctl enable \
  --now file-watcher.service

enable は、Mac mini を再起動した後もサービスを自動的に立ち上げるための指定です。

--now を付けると、有効化と同時にサービスが起動します。
動作状態は、次のコマンドで確認できます。

systemctl status \
  file-watcher.service

正常に動いていれば、状態欄に次のように表示されます。

Active: active (running)

ログは、次のコマンドで確認できます。

journalctl \
  -u file-watcher.service \
  -n 30 \
  --no-pager

MacBookPro から画像を一枚コピーすると、ログへ検知と安定確認の記録が残ります。

ファイル到着を検知、コピー完了待ち
ファイル準備完了

これで、ターミナルを閉じても監視は続きます。

Mac mini を再起動しても、共有フォルダの監視は自動的に戻ります。

まずは、一枚で確かめる

監視が動いた後も、すぐに大量の画像を入れることはしませんでした。

最初は一枚だけです。
一枚をコピーし、ログを確認します。
次に数枚を入れ、取りこぼしがないかを確かめます。

さらに、コピー中のファイルを早く読み始めていないか、隠しファイルを誤って拾っていないかを見ます。

小さな試験であれば、問題が起きても追いかけられます。

大量のファイルを投入してから異常に気づくと、原因を探すだけでも相応の時間が必要になります。

安価な機械だから慎重に扱うのではありません。

大切なものを預ける仕組みである以上、価格にかかわらず、確かめながら進める必要があります。

監視できなかった時間を補う

ここまでで、新しく届く画像は検知できるようになりました。

ただし、ひとつだけ残る問題があります。
サービスが停止している間に置かれた画像です。

監視プログラムが動いていなければ、ファイルが作成された瞬間の通知は受け取れません。そこで実際の構成では、サービスの起動時に inbox の中を確認し、まだ登録されていないファイルを探す「起動時照合」も加えました。

これは、監視をより確かなものにするための補助です。
また、後に大量の画像を扱った際には、処理部分を4並列へ変更しました。ただし、通常のファイル到着では、コピー完了を確認する3秒間の待機を残しています。

速くすることよりも、正しく受け取ることを先に置きました。
起動時照合や並列処理については、画像情報をデータベースへ記録する次回以降で、改めて触れます。

静かに待つという仕事

今回作ったのは、共有フォルダの変化を見守る小さなプログラムです。

画像が届いたことに気づきます。けれど、すぐには触れません。
容量と更新時刻を見ながら、コピーが終わるまで待ちます。隠しファイルは受け流し、同じ通知を重ねて処理しないようにします。

そして、systemdの管理下で、ターミナルを閉じた後も働き続けます。

完成した画面のような華やかさは、まだありません。
それでも、この段階を曖昧なまま先へ進めることはできませんでした。
受け取る仕組みが不確かであれば、その後にどれほど情報を加えても、記録そのものを信頼できないからです。

古い Mac mini に与えた最初の実務は、画像を急いで整理することではありませんでした。

誰かが置いたことに気づき、届き終えるまで静かに待つことです。

その控えめな仕事が、後に30,407枚を預かる画像ライブラリの土台になりました。

次回

次回は、受け取った画像の情報をSQLiteへ記録します。

ファイル名、容量、更新日時、画像の縦横寸法、MIMEタイプに加え、SHA-256と呼ばれる値も保存します。

SHA-256とは、ファイルの内容から算出する、いわばデータの指紋です。この値を手掛かりに、名前が異なる同一画像も見つけられるようにします。

ただ到着を見守るだけだったMac miniが、次回からは、預かった画像を一枚ずつ覚え始めます。

最後までご覧いただきましてありがとうございました。