62574
.NET Core コンソールアプリを作成しています。  
Linux 上で cron
を使用し、定期的に動作させることを想定していますが、同じプログラムが実行中の場合は、実行しない（すぐに終了する）ようにしたいです。  
OS が Windows の場合は Mutex（グローバルミューテックス？）を使用することが出来ますが、Linux でも同じように Mutex
を使用することは出来るのでしょうか。  
または他の方法を使用する必要がありますか。  
二重起動を抑止するには、どのようにコーディングすればよいでしょうか。
CC BY-SA 4.0
2020-01-27T02:51:31.447
62573
2020-01-27T03:51:38.943
3925
question
c# linux .net .net-core
.NET Core コンソールアプリの Linux での二重起動防止
.NET Coreで名前付きMutexがサポートされているようです。  
Windows上での動作と同様に使えるのではないでしょうか？  
試してみてください。

Unityに関する質問で、それには答えが付いていませんが、記事には.NET Core コンソールアプリケーションで正常に動作しているとあります。  
[Mutex on Linux](https://answers.unity.com/questions/1606222/mutex-on-
linux.html)

> If I want to use named mutexes on Linux I need to put Global\ before the
> name, e.g. Global\Mutex. But the thing is if I try to do that in Unity the
> client cannot find the Mutex with that name, however, when I call the same
> method from .NET Core console app it works normally.
>
> Linuxで名前付きミューテックスを使用する場合は、名前の前にGlobal\を置く必要があります。 Global\Mutex。
> ただし、Unityでそれを行おうとすると、クライアントはその名前のMutexを見つけることができませんが、.NET
> Coreコンソールアプリから同じメソッドを呼び出すと、正常に動作します。

他にこの辺の記事で経緯等のちょっとした情報が記載されています。  
[CoreCLR - A bug story about named mutex on
Mono](https://aakinshin.net/posts/namedmutex-on-mono/#coreclr)

> Mono is not the only xplat .NET runtime; we also have CoreCLR! How are
> things going with named mutexes on Linux and MacOS here?
>
> Early versions of CoreCLR just throw a PlatformNotSupportedException when
> users try to create named primitives (see coreclr#1387, corefx#2796). It
> wasn't great because there is a lot of legacy code which already uses named
> mutexes. So, after some discussions (e.g., see coreclr#1237, coreclr#3422),
> the cross-process named mutexes were implemented. Here is an awesome PR by
> @kouvel: coreclr#5030. A fragment from the issue summary:
>
>   * On systems that support pthread process-shared robust recursive mutexes,
> they will be used
>   * On other systems, file locks are used. File locks unfortunately don't
> have a timeout in the blocking wait call, and I didn't find any other sync
> object with a timed wait with the necessary properties, so polling is done
> for timed waits.
>

>
> Conclusion  
>  When you write cross-platform .NET applications, think twice before using
> any OS-specific API. Always check how it's implemented on your favorite
> runtime (Mono or CoreCLR).
>
> xplat
> .NETランタイムはMonoだけではありません。CoreCLRもあります！LinuxとMacOSでの名前付きミューテックスはどうなっているのですか？
>
>
> ユーザーが名前付きプリミティブを作成しようとすると、CoreCLRの初期バージョンではPlatformNotSupportedExceptionがスローされます（coreclr＃1387、corefx＃2796を参照）。すでに名前付きミューテックスを使用している多くのレガシーコードがあるため、それは素晴らしいことではありませんでした。そのため、いくつかの議論（たとえば、coreclr＃1237、coreclr＃3422を参照）の後、ミューテックスという名前のクロスプロセスが実装されました。これは@kouvelによる素晴らしいPR
> です：coreclr ＃5030。問題の概要からの断片：
>
>   * pthreadプロセス共有の堅牢な再帰mutexをサポートするシステムでは、それらが使用されます
>   *
> 他のシステムでは、ファイルロックが使用されます。残念ながら、ブロックロックの待機呼び出しにはファイルロックのタイムアウトがありません。また、必要なプロパティを備えた時間制限のある他の同期オブジェクトが見つからなかったため、時間制限のポーリングが行われます。
>

>
> 結論  
>
> クロスプラットフォームの.NETアプリケーションを作成するときは、OS固有のAPIを使用する前によく考えてください。お気に入りのランタイム（MonoまたはCoreCLR）での実装方法を常に確認してください。

そして以下が上記からリンクされていたCoreCLRでの対応Issue記事です。  
対応内容の詳細が記述されています。  
[Add named mutex for cross-process
synchronization](https://github.com/dotnet/coreclr/pull/5030)

現在の日本語ドキュメント  
[Mutex クラス](https://docs.microsoft.com/ja-
jp/dotnet/api/system.threading.mutex?view=netcore-3.1)

> 同期プリミティブは、プロセス間の同期にも使用できます。
>
> 適用対象  
>  .NET Core  
>  3.1 3.0 2.2 2.1 2.0 1.1 1.0
CC BY-SA 4.0
2020-01-27T03:43:15.140
62574
2020-01-27T03:51:38.943
2020-01-27T03:51:38.943
26370
26370
62573
answer