-
Notifications
You must be signed in to change notification settings - Fork 5k
Delete runtime built-in handling for SIGTERM #115494
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
Conversation
The runtime build-in handling for SIGTERM signals is not correct for all appmodels. It is better to leave it to each model appmodel to handle it in appmodel specific way if necessary. The popular console appmodel based on HostingHostBuilderExtensions.UseConsoleLifetime does that already. Fixes dotnet#115206
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR removes the runtime built-in SIGTERM handling to let each appmodel handle SIGTERM in an appmodel-specific way—aligning with the improvements provided by HostingHostBuilderExtensions.UseConsoleLifetime. The changes remove related debug variables, signal handling functions, and associated worker thread commands to simplify and standardize signal handling.
Reviewed Changes
Copilot reviewed 11 out of 11 changed files in this pull request and generated no comments.
Show a summary per file
File | Description |
---|---|
src/coreclr/vm/vars.hpp and vars.cpp | Removed debug-only variables and assertions related to SIGTERM handling. |
src/coreclr/vm/listlock.h | Simplified assertion by eliminating debug checks tied to termination. |
src/coreclr/vm/exceptionhandling.cpp | Deleted Unix-specific termination request handler and its registration. |
src/coreclr/vm/ceemain.cpp | Removed custom control event handling and flags related to SIGTERM. |
src/coreclr/pal/src/synchmgr/*.hpp and .cpp | Removed termination request command and its associated function. |
src/coreclr/pal/src/include/pal/corunix.hpp | Removed virtual method for termination request handling. |
src/coreclr/pal/inc/pal.h | Removed the termination request handler declaration. |
src/coreclr/pal/src/exception/signal.cpp | Removed call to SendTerminationRequestToWorkerThread and relies on signal restoration. |
src/coreclr/debug/ee/debugger.cpp | Updated assertions to remove dependency on debug flag g_fInControlC. |
Comments suppressed due to low confidence (2)
src/coreclr/pal/src/exception/signal.cpp:846
- Verify that replacing the termination request handling with restore_signal_and_resend reliably propagates the SIGTERM signal in all appmodel scenarios. Consider documenting any behavioral differences that consumers should be aware of.
g_pSynchronizationManager->SendTerminationRequestToWorkerThread();
src/coreclr/debug/ee/debugger.cpp:5905
- The updated assertion removes the check for g_fInControlC; please confirm that this change does not lead to unintended assertion failures in cases where the thread's preemptive GC state might not be set as expected under debugging conditions.
_ASSERTE((g_pEEInterface->GetThread() && !g_pEEInterface->GetThread()->m_fPreemptiveGCDisabled) || g_fInControlC);
This also aligns the behavior between regular CoreCLR and NAOT. |
ForceEEShutdown(SCA_ReturnWhenShutdownComplete); | ||
} | ||
|
||
g_fInControlC = true; // only for weakening assertions in checked build. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no reason to weaken assertions after Ctrl+C has been pressed. The runtime should still function fine until all signal handlers finish.
I think we should |
/azp run runtime-coreclr outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
Indeed, runtime doesn't need to do much on SIGTERM except inform the managed side. This is a nice cleanup! To be sure: does |
It won't unless the app subscribes to the signal and does graceful exit in the signal handler. Typical ASP.NET app does that via ConsoleLifetime today: runtime/src/libraries/Microsoft.Extensions.Hosting/src/Internal/ConsoleLifetime.netcoreapp.cs Lines 20 to 23 in c53ccee
The default handling of SIGTERM will be identical to handling of SIGQUIT or SIGINT with this change. No handler registered by default. E.g. Python is on the same plan according to https://stackoverflow.com/questions/9930576/python-what-is-the-default-handling-of-sigterm |
On Windows, this reverts the behavior to what it used to be in .NET Framework. |
I'm asking because before It's probably worth calling out explicitly in the breaking change doc. |
src/libraries/System.Runtime/tests/System.Runtime.Tests/System/ExitCodeTests.Unix.cs
Show resolved
Hide resolved
src/libraries/System.Runtime/tests/System.Runtime.Tests/System/ExitCodeTests.Unix.cs
Outdated
Show resolved
Hide resolved
…/ExitCodeTests.Unix.cs
Breaking change issue created: dotnet/docs#46226 |
Behavior change introduced by dotnet/runtime#115494
This is a behavior change introduced by dotnet/runtime#115494
* [VMR] Codeflow e26a16c-e26a16c [[ commit created by automation ]] * Update dependencies from https://github.com/dotnet/dotnet build 268973 No dependency updates to commit * Align M.CA package versions * Update dependencies from https://github.com/dotnet/dotnet build 269082 Updated Dependencies: dotnet-ef, Microsoft.EntityFrameworkCore.InMemory, Microsoft.EntityFrameworkCore.Relational, Microsoft.EntityFrameworkCore.Sqlite, Microsoft.EntityFrameworkCore.SqlServer, Microsoft.EntityFrameworkCore.Tools, Microsoft.EntityFrameworkCore, Microsoft.EntityFrameworkCore.Design (Version 10.0.0-preview.4.25269.109 -> 10.0.0-preview.4.25265.101) Microsoft.Extensions.Caching.Abstractions, Microsoft.Extensions.Caching.Memory, Microsoft.Extensions.Configuration.Abstractions, Microsoft.Extensions.Configuration.Binder, Microsoft.Extensions.Configuration.CommandLine, Microsoft.Extensions.Configuration.EnvironmentVariables, Microsoft.Extensions.Configuration.FileExtensions, Microsoft.Extensions.Configuration.Ini, Microsoft.Extensions.Configuration.Json, Microsoft.Extensions.Configuration.UserSecrets, Microsoft.Extensions.Configuration.Xml, Microsoft.Extensions.Configuration, Microsoft.Extensions.DependencyInjection.Abstractions, Microsoft.Extensions.DependencyInjection, Microsoft.Extensions.Diagnostics, Microsoft.Extensions.Diagnostics.Abstractions, Microsoft.Extensions.FileProviders.Abstractions, Microsoft.Extensions.FileProviders.Composite, Microsoft.Extensions.FileProviders.Physical, Microsoft.Extensions.FileSystemGlobbing, Microsoft.Extensions.HostFactoryResolver.Sources, Microsoft.Extensions.Hosting.Abstractions, Microsoft.Extensions.Hosting, Microsoft.Extensions.Http, Microsoft.Extensions.Logging.Abstractions, Microsoft.Extensions.Logging.Configuration, Microsoft.Extensions.Logging.Console, Microsoft.Extensions.Logging.Debug, Microsoft.Extensions.Logging.EventSource, Microsoft.Extensions.Logging.EventLog, Microsoft.Extensions.Logging.TraceSource, Microsoft.Extensions.Logging, Microsoft.Extensions.Options.ConfigurationExtensions, Microsoft.Extensions.Options.DataAnnotations, Microsoft.Extensions.Options, Microsoft.Extensions.Primitives, Microsoft.Internal.Runtime.AspNetCore.Transport, System.Configuration.ConfigurationManager, System.Diagnostics.DiagnosticSource, System.Diagnostics.EventLog, System.DirectoryServices.Protocols, System.Formats.Asn1, System.IO.Pipelines, System.Net.Http.Json, System.Net.Http.WinHttpHandler, System.Net.ServerSentEvents, System.Reflection.Metadata, System.Resources.Extensions, System.Security.Cryptography.Pkcs, System.Security.Cryptography.Xml, System.Security.Permissions, System.ServiceProcess.ServiceController, System.Text.Encodings.Web, System.Text.Json, System.Threading.AccessControl, System.Threading.Channels, System.Threading.RateLimiting, Microsoft.Extensions.DependencyModel, Microsoft.NETCore.App.Ref, Microsoft.NET.Runtime.MonoAOTCompiler.Task, Microsoft.NET.Runtime.WebAssembly.Sdk, Microsoft.Bcl.AsyncInterfaces, Microsoft.Bcl.TimeProvider, System.Collections.Immutable, System.Diagnostics.PerformanceCounter, System.IO.Hashing, System.Memory.Data, System.Numerics.Tensors, System.Runtime.Caching, Microsoft.NETCore.App.Runtime.win-x64, Microsoft.NETCore.App.Runtime.AOT.win-x64.Cross.browser-wasm, Microsoft.NETCore.BrowserDebugHost.Transport, System.Composition, Microsoft.NETCore.Platforms (Version 10.0.0-preview.5.25269.109 -> 10.0.0-preview.5.25265.101) Microsoft.Web.Xdt (Version 10.0.0-preview.25269.109 -> 10.0.0-preview.25265.101) Microsoft.DotNet.HotReload.Agent, Microsoft.DotNet.HotReload.Agent.Data (Version 10.0.100-preview.5.25269.109 -> 10.0.100-preview.5.25265.101) Microsoft.DotNet.Arcade.Sdk, Microsoft.DotNet.Build.Tasks.Archives, Microsoft.DotNet.Build.Tasks.Installers, Microsoft.DotNet.Build.Tasks.Templating, Microsoft.DotNet.Helix.Sdk, Microsoft.DotNet.RemoteExecutor, Microsoft.DotNet.SharedFramework.Sdk (Version 10.0.0-beta.25269.109 -> 10.0.0-beta.25265.101) * Add System.Threading.AccessControl to expected assemblies It was added in dotnet/runtime#110416 * Adjust expected exit code in ShutdownTests.cs This is a behavior change introduced by dotnet/runtime#115494 * Fix method name, kill by default sends TERM not INT * Revert "Adjust expected exit code in ShutdownTests.cs" This reverts commit 3c695d2. * React to dotnet/runtime#115494 --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Matt Thalman <[email protected]> Co-authored-by: Alexander Köplinger <[email protected]> Co-authored-by: Jan Kotas <[email protected]>
The runtime built-in handling for SIGTERM signals is not correct for all appmodels. It is better to leave it to each model appmodel to handle it in appmodel specific way if necessary. The popular console appmodel based on HostingHostBuilderExtensions.UseConsoleLifetime does that already.
Fixes #83093