What happens if the same process runs twice? Preventing duplicate execution with Linux flock and Windows Named Mutex

Linux・CLI・DevOpsカテゴリを表すパンダのイラスト Linux / CLI / DevOps

About this article
This article is created using an automated workflow powered by generative AI. By verifying the primary sources for Linux flock and .NET Named Mutex, we compare how Linux and Windows prevent the same scheduled process from running twice under the same criteria.

Verification Status: 🧪 Linux flock execution verified. Windows Mutex verified against official specifications.
Information Verification Baseline Date: October 5, 2026

In scheduled processes like cron, systemd timers, and the Windows Task Scheduler, a new execution may sometimes start before the previous one has finished. For tasks such as backups, file updates, and blog posting, duplicate execution causes redundant processing and race conditions.

The fundamental way to prevent this incident isexclusive locking.

Running flock twice on Linux

Execute this in Terminal 1.

flock -n /tmp/papanda-demo.lock   bash -c 'echo "LOCK取得"; sleep 10; echo "LOCK解除"'

Execute the same command from Terminal 2 within 10 seconds.-n specifies that execution terminates immediately without waiting if the lock cannot be acquired.

By overlapping two processes in this environment,we confirmed that the second process could not acquire the lock.

flowchart TD
    A["処理A 起動"] --> B{"flock取得?"}
    B -- Yes --> C["処理Aを実行"]
    D["処理B 起動"] --> E{"同じflock取得?"}
    E -- No --> F["二重実行せず終了"]
    C --> G["処理終了・lock解放"]

The state cannot be determined solely by the presence of a lock file

/tmp/papanda-demo.lockWhen seeing a filename like this, it looks as though the file itself holds the lock state.

util-linux's flock handles locks on files, directories, or open file descriptors. Therefore,The existence of a filename is not the same as the current lock being held.

Before deciding in production that "the lock file remains so we should just delete it," verify the owning process and service status.

Define a timeout if you are going to wait

Instead of failing immediately, you can wait for a specified duration.

flock -w 10 /tmp/papanda-demo.lock   bash -c 'echo "処理開始"; sleep 20; echo "処理終了"'

For scheduled tasks, determine whether to "give up immediately," "wait a few seconds," or "notify monitoring" when a lock cannot be acquired.

Named Mutexes can be used on Windows

The .NET System.Threading.Mutex is mutual exclusion control that can also be used for inter-process synchronization.

$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()
}

If you open two PowerShell instances and execute the second one while the first is waiting for 5 seconds, you can determine multiple instance execution based on whether the Mutex with the same name can be acquired.

This Windows-specific part has not been verified on real hardware, so it is not treated as actual measurement results.

Local and Global are not the same

In this tutorial material, Local\PapandaLockDemo is used.

For cross-session use cases, Global\ comes into play, but permissions and operational requirements also change. Decide first which processes you want to exclude from each other.

Consider Mutexes that terminated abnormally as well

In .NET, if the thread that owned the Mutex terminates without releasing it, the next acquiring side may throw AbandonedMutexException .

This indicates that the previous process may have ended prematurely. The design must include checks to ensure that the files or data being protected are not left in an inconsistent state.

Deadlocks can also occur with multiple locks

処理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

The basics of mitigation are standardizing the acquisition order, reducing the holding time, setting timeouts, and avoiding the addition of unnecessary locks.

In periodic processing, separate the lock acquisition from the success or failure of the main process.

For backups,

起動
↓
ロック取得
↓
取得できなければ「前回処理中」として終了
↓
バックアップ実行
↓
結果確認
↓
ロック解放

becomes as follows.

Acquiring a lock does not mean the backup was successful. Record the success or failure of the main process separately.

Commonalities between Linux and Windows

Linux flockWindows Named Mutex
Can exclude concurrent executionCan exclude concurrent execution
Uses file/FDOS named synchronization object
-n / -w controls how to waitWaitOne(timeout) controls how to wait
Do not determine the state based solely on the lock file nameMutex acquisition alone does not guarantee the consistency of protected data

Although the implementation methods differ, the design questions remain the same.Determine who you will contend with, whether to wait or give up if the lock cannot be acquired, and what to verify after an abnormal termination.is decided.

Daily-Code-Samples

Official Information

Document information

Article title
What happens if the same process runs twice? Preventing duplicate execution with Linux flock and Windows Named Mutex
Published
Updated
Source
https://papanda925.com/?p=17995&lang=en

License: Text and original figures for which this site holds the relevant rights are available under CC BY 4.0 , unless otherwise noted. This article may include content created or edited with generative AI. If code has a separate license notice or a linked GitHub repository license, that license takes precedence for the code. Quotations, third-party materials, images, and trademarks are excluded from this license. Usage policy

Copied title and URL