Skip to content

[Breaking change]: .NET runtime no longer provides default SIGTERM signal handler #46226

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
1 of 3 tasks
jkotas opened this issue May 15, 2025 · 0 comments
Open
1 of 3 tasks
Assignees
Labels
breaking-change Indicates a .NET Core breaking change ⌚ Not Triaged Not triaged

Comments

@jkotas
Copy link
Member

jkotas commented May 15, 2025

Description

On Unix systems, .NET runtime no longer provides default SIGTERM signal handler. On Windows, .NET runtime no longer provides default handler for CTRL_CLOSE_EVENT and CTRL_SHUTDOWN_EVENT signals that are equivalents of Unix SIGTERM signal.

This change reverts the SIGTERM signal handling behavior to what it used to be in .NET Framework and classic Mono runtime.

Version

.NET 10 Preview 5

Previous behavior

SIGTERM signal handler registered by .NET runtime by default triggers graceful application exit. AppDomain.ProcessExit and AssemblyLoadContext.Unloading events are raised before application exits.

New behavior

.NET runtime does not override SIGTERM signal handling provided by the operating system. The typical default SIGTERM signal handler provided by the operating system terminates the application immediately. AppDomain.ProcessExit or AssemblyLoadContext.Unloading events are not raised

Type of breaking change

  • Binary incompatible: Existing binaries might encounter a breaking change in behavior, such as failure to load or execute, and if so, require recompilation.
  • Source incompatible: When recompiled using the new SDK or component or to target the new runtime, existing source code might require source changes to compile successfully.
  • Behavioral change: Existing binaries might behave differently at run time.

Reason for change

SIGTERM signal handler registered by .NET runtime by default was both insufficient for some app models (e.g. console and containerized application) and incompatible with other app models (e.g. Windows services). It is better to leave it to higher level libraries or application code to register signal handlers appropriate for given app model.

Recommended action

  • No action is necessary for typical ASP.NET applications or applications that use higher level APIs such as HostingHostBuilderExtensions.UseConsoleLifetime to handle app-model specific concerns. These higher-level APIs register handlers for SIGTERM and other signals as appropriate.

  • Applications that wish to handle SIGTEM signal without taking a dependency on higher level libraries can replicate the old behavior by creating a SIGTERM signal handler in their Main method using PosixSignalRegistration.Create API:

    static void Main()
    {
        using var termSignalRegistration = PosixSignalRegistration.Create(PosixSignal.SIGTERM, (_) => Environment.Exit(0));

        ...
    }

Feature area

Core .NET libraries

Affected APIs

AppDomain.ProcessExit
AssemblyLoadContext.Unloading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change Indicates a .NET Core breaking change ⌚ Not Triaged Not triaged
Projects
Status: 🔖 Ready
Development

No branches or pull requests

2 participants