From 018d94ff72bfd99a8f22118f939db9a7745a88b8 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Fri, 6 Jun 2025 23:14:01 +0000 Subject: [PATCH 1/3] Initial plan for issue From 8907d2a825641a8ada7c8ef300ea2a25cadabeee Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Fri, 6 Jun 2025 23:27:43 +0000 Subject: [PATCH 2/3] Add breaking change documentation for SIGTERM signal handler removal Co-authored-by: gewarren <24882762+gewarren@users.noreply.github.com> --- docs/core/compatibility/10.0.md | 1 + .../10.0/sigterm-signal-handler.md | 55 +++++++++++++++++++ docs/core/compatibility/toc.yml | 2 + 3 files changed, 58 insertions(+) create mode 100644 docs/core/compatibility/core-libraries/10.0/sigterm-signal-handler.md diff --git a/docs/core/compatibility/10.0.md b/docs/core/compatibility/10.0.md index c48414e0e42fd..cabfa0ec09da7 100644 --- a/docs/core/compatibility/10.0.md +++ b/docs/core/compatibility/10.0.md @@ -32,6 +32,7 @@ If you're migrating an app to .NET 10, the breaking changes listed here might af | [Default trace context propagator updated to W3C standard](core-libraries/10.0/default-trace-context-propagator.md) | Behavioral change | Preview 4 | | [LDAP DirectoryControl parsing is now more stringent](core-libraries/10.0/ldap-directorycontrol-parsing.md) | Behavioral change | Preview 1 | | [MacCatalyst version normalization](core-libraries/10.0/maccatalyst-version-normalization.md) | Behavioral change | Preview 1 | +| [.NET runtime no longer provides default SIGTERM signal handler](core-libraries/10.0/sigterm-signal-handler.md) | Behavioral change | Preview 5 | | [System.Linq.AsyncEnumerable included in core libraries](core-libraries/10.0/asyncenumerable.md) | Source incompatible | Preview 1 | ## Extensions diff --git a/docs/core/compatibility/core-libraries/10.0/sigterm-signal-handler.md b/docs/core/compatibility/core-libraries/10.0/sigterm-signal-handler.md new file mode 100644 index 0000000000000..cb8aefad738f7 --- /dev/null +++ b/docs/core/compatibility/core-libraries/10.0/sigterm-signal-handler.md @@ -0,0 +1,55 @@ +--- +title: "Breaking change: .NET runtime no longer provides default SIGTERM signal handler" +description: "Learn about the breaking change in .NET 10 where the runtime no longer provides a default SIGTERM signal handler." +ms.date: 01/30/2025 +ai-usage: ai-assisted +ms.custom: https://github.com/dotnet/docs/issues/46226 +--- +# .NET runtime no longer provides default SIGTERM signal handler + +On Unix systems, .NET runtime no longer provides a default SIGTERM signal handler. On Windows, .NET runtime no longer provides default handlers 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 introduced + +.NET 10 Preview 5 + +## Previous behavior + +Previously, a SIGTERM signal handler registered by .NET runtime by default triggered graceful application exit. and events were raised before the application exited. + +## New behavior + +Starting in .NET 10, .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. and events are not raised. + +## Type of breaking change + +This is a [behavioral change](../../categories.md#behavioral-change). + +## Reason for change + +The SIGTERM signal handler registered by .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. + +## 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 SIGTERM 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 API: + +```csharp +using System; +using System.Runtime.InteropServices; + +static void Main() +{ + using var termSignalRegistration = PosixSignalRegistration.Create(PosixSignal.SIGTERM, (_) => Environment.Exit(0)); + + // Your application code here +} +``` + +## Affected APIs + +- +- diff --git a/docs/core/compatibility/toc.yml b/docs/core/compatibility/toc.yml index b23ec8647832f..b918ace20df7c 100644 --- a/docs/core/compatibility/toc.yml +++ b/docs/core/compatibility/toc.yml @@ -28,6 +28,8 @@ items: href: core-libraries/10.0/ldap-directorycontrol-parsing.md - name: MacCatalyst version normalization href: core-libraries/10.0/maccatalyst-version-normalization.md + - name: .NET runtime no longer provides default SIGTERM signal handler + href: core-libraries/10.0/sigterm-signal-handler.md - name: System.Linq.AsyncEnumerable included in core libraries href: core-libraries/10.0/asyncenumerable.md - name: Cryptography From 45da191bc094b8f4589a5f12149c8d14f5734349 Mon Sep 17 00:00:00 2001 From: Genevieve Warren <24882762+gewarren@users.noreply.github.com> Date: Fri, 6 Jun 2025 17:15:14 -0700 Subject: [PATCH 3/3] human edits --- .../10.0/sigterm-signal-handler.md | 22 +++++++++---------- docs/core/compatibility/toc.yml | 4 +++- 2 files changed, 14 insertions(+), 12 deletions(-) diff --git a/docs/core/compatibility/core-libraries/10.0/sigterm-signal-handler.md b/docs/core/compatibility/core-libraries/10.0/sigterm-signal-handler.md index cb8aefad738f7..80a6b852008a5 100644 --- a/docs/core/compatibility/core-libraries/10.0/sigterm-signal-handler.md +++ b/docs/core/compatibility/core-libraries/10.0/sigterm-signal-handler.md @@ -1,13 +1,13 @@ --- title: "Breaking change: .NET runtime no longer provides default SIGTERM signal handler" description: "Learn about the breaking change in .NET 10 where the runtime no longer provides a default SIGTERM signal handler." -ms.date: 01/30/2025 +ms.date: 06/06/2025 ai-usage: ai-assisted ms.custom: https://github.com/dotnet/docs/issues/46226 --- # .NET runtime no longer provides default SIGTERM signal handler -On Unix systems, .NET runtime no longer provides a default SIGTERM signal handler. On Windows, .NET runtime no longer provides default handlers for `CTRL_CLOSE_EVENT` and `CTRL_SHUTDOWN_EVENT` signals that are equivalents of Unix `SIGTERM` signal. +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. This change reverts the SIGTERM signal handling behavior to what it used to be in .NET Framework and classic Mono runtime. @@ -17,11 +17,11 @@ This change reverts the SIGTERM signal handling behavior to what it used to be i ## Previous behavior -Previously, a SIGTERM signal handler registered by .NET runtime by default triggered graceful application exit. and events were raised before the application exited. +Previously, a SIGTERM signal handler registered by the .NET runtime by default triggered graceful application exit. and events were raised before the application exited. ## New behavior -Starting in .NET 10, .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. and events are not raised. +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. and events aren't raised. ## Type of breaking change @@ -29,21 +29,21 @@ This is a [behavioral change](../../categories.md#behavioral-change). ## Reason for change -The SIGTERM signal handler registered by .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. +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. ## 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. +- No action is necessary for typical ASP.NET applications or applications that use higher-level APIs such as to handle app-model specific concerns. These higher-level APIs register handlers for SIGTERM and other signals as appropriate. -- Applications that wish to handle SIGTERM 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 API: +- 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 API: ```csharp -using System; -using System.Runtime.InteropServices; - static void Main() { - using var termSignalRegistration = PosixSignalRegistration.Create(PosixSignal.SIGTERM, (_) => Environment.Exit(0)); + using var termSignalRegistration = + PosixSignalRegistration.Create( + PosixSignal.SIGTERM, + (_) => Environment.Exit(0)); // Your application code here } diff --git a/docs/core/compatibility/toc.yml b/docs/core/compatibility/toc.yml index b918ace20df7c..23a5c43709ced 100644 --- a/docs/core/compatibility/toc.yml +++ b/docs/core/compatibility/toc.yml @@ -28,7 +28,7 @@ items: href: core-libraries/10.0/ldap-directorycontrol-parsing.md - name: MacCatalyst version normalization href: core-libraries/10.0/maccatalyst-version-normalization.md - - name: .NET runtime no longer provides default SIGTERM signal handler + - name: No default SIGTERM signal handler href: core-libraries/10.0/sigterm-signal-handler.md - name: System.Linq.AsyncEnumerable included in core libraries href: core-libraries/10.0/asyncenumerable.md @@ -1414,6 +1414,8 @@ items: href: core-libraries/10.0/ldap-directorycontrol-parsing.md - name: MacCatalyst version normalization href: core-libraries/10.0/maccatalyst-version-normalization.md + - name: No default SIGTERM signal handler + href: core-libraries/10.0/sigterm-signal-handler.md - name: System.Linq.AsyncEnumerable included in core libraries href: core-libraries/10.0/asyncenumerable.md - name: .NET 9