Skip to content

SharedMemoryHelpers.CreateOrOpenFile throws IOException 'already exists' for NuGet-Migrations named mutex on Linux #125632

Closed

Description

@lewing

Description

dotnet CLI first-run experience fails intermittently on Linux with:

System.IO.IOException: The file '/tmp/.dotnet/shm/session1/NuGet-Migrations' already exists.
   at System.IO.SharedMemoryHelpers.CreateOrOpenFile(String sharedMemoryFilePath, SharedMemoryId id, Boolean createIfNotExist, Boolean& createdFile)
   at System.IO.SharedMemoryProcessDataHeader`1.CreateOrOpen(...)
   at System.Threading.NamedMutexProcessDataBase.CreateOrOpen(...)
   at System.Threading.WaitSubsystem.NamedMutex.CreateNamedMutex(...)
   at System.Threading.Mutex.CreateMutexCore(...)
   at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name)
   at NuGet.Common.Migrations.MigrationRunner.Run(...)
   at Microsoft.DotNet.Configurer.DotnetFirstTimeUseConfigurer.Configure()
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, TimeSpan startupTime)

This is blocking the VMR official build (dotnet-unified-build definition 1330) on main. Observed in:

  • Build 20260316.1 — ValidateInstallers_Linux_x64 job, DebScenarioTest(repo: "mcr.microsoft.com/dotnet/runtime-deps", tag: "10.0-noble")

The VerifyConsoleTemplateComplex(CSharp) scenario test runs dotnet new console inside a Docker container. A prior dotnet invocation in the same container created the shared memory file at /tmp/.dotnet/shm/session1/NuGet-Migrations. The second invocation's CreateOrOpenFile throws IOException instead of opening the existing file.

Expected behavior

SharedMemoryHelpers.CreateOrOpenFile should handle the case where the shared memory file already exists from a previous process, either by opening it or by recreating it.

Actual behavior

Throws System.IO.IOException: The file ... already exists and the dotnet command fails with exit code 1.

Relation to prior issue

dotnet/runtime#80619 tracked a similar NuGet-Migrations mutex failure on Windows (The system cannot open the device or file specified) in .NET 7/8 timeframe. That issue was fixed and closed in Aug 2023. This appears to be a different codepath — the new SharedMemoryProcessDataHeader / SharedMemoryHelpers implementation on Linux.

Activity

  1. dotnet-policy-service commented on Mar 16, 2026

    @dotnet-policy-service
    Contributor

    Tagging subscribers to this area: @agocke, @VSadov
    See info in area-owners.md if you want to be subscribed.

  2. stephentoub commented on Mar 16, 2026

    @stephentoub
    Member

    I assume this is what @steveisok is trying to address with #125524 ?

  3. added a commit that references this issue on Mar 16, 2026
    67edebe
  4. lewing commented on Mar 16, 2026

    @lewing
    MemberAuthor

    Duplicate of #91987. Fix is in PR #125524.

  5. locked and limited conversation to collaborators on Apr 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions