|
| 1 | +--- |
| 2 | +title: "Breaking change: .NET runtime no longer provides default SIGTERM signal handler" |
| 3 | +description: "Learn about the breaking change in .NET 10 where the runtime no longer provides a default SIGTERM signal handler." |
| 4 | +ms.date: 06/06/2025 |
| 5 | +ai-usage: ai-assisted |
| 6 | +ms.custom: https://github.com/dotnet/docs/issues/46226 |
| 7 | +--- |
| 8 | +# .NET runtime no longer provides default SIGTERM signal handler |
| 9 | + |
| 10 | +On Unix systems, the .NET runtime no longer provides a default SIGTERM signal handler. On Windows, the .NET runtime no longer provides default handlers for the [`CTRL_CLOSE_EVENT` and `CTRL_SHUTDOWN_EVENT` signals](/windows/console/handlerroutine), which are equivalents of Unix `SIGTERM` signal. |
| 11 | + |
| 12 | +This change reverts the SIGTERM signal handling behavior to what it used to be in .NET Framework and classic Mono runtime. |
| 13 | + |
| 14 | +## Version introduced |
| 15 | + |
| 16 | +.NET 10 Preview 5 |
| 17 | + |
| 18 | +## Previous behavior |
| 19 | + |
| 20 | +Previously, a SIGTERM signal handler registered by the .NET runtime by default triggered graceful application exit. <xref:System.AppDomain.ProcessExit?displayProperty=nameWithType> and <xref:System.Runtime.Loader.AssemblyLoadContext.Unloading?displayProperty=nameWithType> events were raised before the application exited. |
| 21 | + |
| 22 | +## New behavior |
| 23 | + |
| 24 | +Starting in .NET 10, the .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. <xref:System.AppDomain.ProcessExit?displayProperty=nameWithType> and <xref:System.Runtime.Loader.AssemblyLoadContext.Unloading?displayProperty=nameWithType> events aren't raised. |
| 25 | + |
| 26 | +## Type of breaking change |
| 27 | + |
| 28 | +This is a [behavioral change](../../categories.md#behavioral-change). |
| 29 | + |
| 30 | +## Reason for change |
| 31 | + |
| 32 | +The SIGTERM signal handler registered by the .NET runtime by default was both insufficient for some app models (for example, console and containerized applications) and incompatible with other app models (for example, Windows services). It's better to leave it to higher-level libraries or application code to register signal handlers appropriate for the given app model. |
| 33 | + |
| 34 | +## Recommended action |
| 35 | + |
| 36 | +- No action is necessary for typical ASP.NET applications or applications that use higher-level APIs such as <xref:Microsoft.Extensions.Hosting.HostingHostBuilderExtensions.UseConsoleLifetime*?displayProperty=nameWithType> to handle app-model specific concerns. These higher-level APIs register handlers for SIGTERM and other signals as appropriate. |
| 37 | + |
| 38 | +- If you want to handle SIGTERM signal without taking a dependency on higher-level libraries, you can replicate the previous behavior by creating a SIGTERM signal handler in your `Main` method using the <xref:System.Runtime.InteropServices.PosixSignalRegistration.Create%2A?displayProperty=nameWithType> API: |
| 39 | + |
| 40 | +```csharp |
| 41 | +static void Main() |
| 42 | +{ |
| 43 | + using var termSignalRegistration = |
| 44 | + PosixSignalRegistration.Create( |
| 45 | + PosixSignal.SIGTERM, |
| 46 | + (_) => Environment.Exit(0)); |
| 47 | + |
| 48 | + // Your application code here |
| 49 | +} |
| 50 | +``` |
| 51 | + |
| 52 | +## Affected APIs |
| 53 | + |
| 54 | +- <xref:System.AppDomain.ProcessExit?displayProperty=fullName> |
| 55 | +- <xref:System.Runtime.Loader.AssemblyLoadContext.Unloading?displayProperty=fullName> |
0 commit comments