この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。Linuxのflockと.NETのNamed Mutexの一次情報を確認し、「同じ定期処理が2回起動したらどう止めるか」をLinuxとWindowsで同じ観点から比べます。検証ステータス：🧪 Linux flock実行確認済み・Windows Mutexは公式仕様確認済み
情報確認基準日：2026年10月5日
cron、systemd timer、Windowsタスクスケジューラなどの定期処理では、前回処理が終わる前に次の実行が始まることがあります。バックアップ、ファイル更新、ブログ投稿のような処理では、二重起動が重複処理や競合の原因になります。
この事故を止める基本が排他ロックです。
Linuxではflockを2回起動してみる
ターミナル1で実行します。
flock -n /tmp/papanda-demo.lock bash -c 'echo "LOCK取得"; sleep 10; echo "LOCK解除"'
10秒以内にターミナル2から同じコマンドを実行します。-n はロックを取れなければ待ち続けず終了する指定です。
この環境で2プロセスを重ね、2つ目がロックを取れないことを確認しました。
flowchart TD
A["処理A 起動"] --> B{"flock取得?"}
B -- Yes --> C["処理Aを実行"]
D["処理B 起動"] --> E{"同じflock取得?"}
E -- No --> F["二重実行せず終了"]
C --> G["処理終了・lock解放"]
lockファイルの存在だけでは状態を断定できない
/tmp/papanda-demo.lock のようなファイル名を見ると、そのファイル自体がロックの状態を持っているように見えます。
util-linuxの flock は、ファイルやディレクトリ、または開いたファイルディスクリプタに対するロックを扱います。そのため、ファイル名が存在することと、現在ロックが保持されていることは同じではありません。
本番で「lockファイルが残っているから消せばよい」と判断する前に、所有プロセスやサービス状態を確認します。
待つならtimeoutを決める
すぐ失敗させる代わりに、一定時間だけ待てます。
flock -w 10 /tmp/papanda-demo.lock bash -c 'echo "処理開始"; sleep 20; echo "処理終了"'
定期処理では、ロックを取れないときに「すぐ諦める」「数秒待つ」「監視へ通知する」のどれにするかを決めておきます。
WindowsではNamed Mutexを使える
.NETの System.Threading.Mutex は、プロセス間の同期にも使える排他制御です。
$mutex = [System.Threading.Mutex]::new(
$false,
"Local\PapandaLockDemo"
)
$locked = $mutex.WaitOne(0)
if ($locked) {
try {
Write-Host "[SUCCESS] LOCK取得"
Start-Sleep -Seconds 5
}
finally {
$mutex.ReleaseMutex()
$mutex.Dispose()
}
}
else {
Write-Host "[BLOCKED] 別プロセスが実行中"
$mutex.Dispose()
}
PowerShellを2つ開き、1つ目の5秒待機中に2つ目を実行すると、同じ名前のMutexを取得できるかで二重起動を判定できます。
このWindows部分は実機未確認なので、実測結果としては扱っていません。
LocalとGlobalは同じではない
今回の教材では Local\PapandaLockDemo を使います。
セッションをまたぐ用途などでは Global\ が関係しますが、権限や運用条件も変わります。「どのプロセス同士を排他したいのか」を先に決めます。
異常終了したMutexも考える
.NETではMutexを所有したスレッドがReleaseせず終了した場合、次に取得する側で AbandonedMutexException が発生することがあります。
これは前の処理が途中で終了した可能性を示します。保護対象のファイルやデータが中途半端になっていないか確認する設計が必要です。
複数ロックではデッドロックも起こる
処理A: LOCK-1取得 → LOCK-2待ち 処理B: LOCK-2取得 → LOCK-1待ち
flowchart LR
A["処理A<br>LOCK-1保持"] --> B["LOCK-2待ち"]
C["処理B<br>LOCK-2保持"] --> D["LOCK-1待ち"]
B --> C
D --> A
対策の基本は、取得順序の統一、保持時間の短縮、timeout、不要なロックを増やさないことです。
定期処理ではロック取得と本処理の成否を分ける
バックアップなら、
起動 ↓ ロック取得 ↓ 取得できなければ「前回処理中」として終了 ↓ バックアップ実行 ↓ 結果確認 ↓ ロック解放
となります。
ロックを取れたことはバックアップ成功を意味しません。本処理の成功・失敗は別に記録します。
LinuxとWindowsの共通点
| Linux flock | Windows Named Mutex |
|---|---|
| 同時実行を排他できる | 同時実行を排他できる |
| file/FDを利用 | OSの名前付き同期オブジェクト |
-n / -w で待ち方を制御 | WaitOne(timeout) で待ち方を制御 |
| lockファイル名だけでは状態を断定しない | Mutex取得だけでは保護データの整合性は保証しない |
実装方法は違っても、設計上の問いは同じです。誰と競合するのか、取れなければ待つか諦めるか、異常終了後に何を確認するかを決めます。
