Skip to content

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

Merged
merged 6 commits into from
May 15, 2025
Merged

Conversation

jkotas
Copy link
Member

@jkotas jkotas commented May 12, 2025

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

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
@Copilot Copilot AI review requested due to automatic review settings May 12, 2025 21:39
Copy link
Contributor

@Copilot Copilot AI left a 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);

@jkotas jkotas added the breaking-change Issue or PR that represents a breaking API or functional change over a prerelease. label May 12, 2025
@dotnet-policy-service dotnet-policy-service bot added the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label May 12, 2025
@jkotas
Copy link
Member Author

jkotas commented May 12, 2025

This also aligns the behavior between regular CoreCLR and NAOT.

ForceEEShutdown(SCA_ReturnWhenShutdownComplete);
}

g_fInControlC = true; // only for weakening assertions in checked build.
Copy link
Member Author

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.

@jkotas
Copy link
Member Author

jkotas commented May 12, 2025

cc @am11 @tmds @omajid

@am11
Copy link
Member

am11 commented May 12, 2025

I think we should /azp run runtime-coreclr outerloop on this one which covers some relevant cases in PALTests etc.

@jkotas
Copy link
Member Author

jkotas commented May 12, 2025

/azp run runtime-coreclr outerloop

@dotnet dotnet deleted a comment from azure-pipelines bot May 12, 2025
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Copy link
Member

@am11 am11 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

@tmds
Copy link
Member

tmds commented May 13, 2025

Indeed, runtime doesn't need to do much on SIGTERM except inform the managed side. This is a nice cleanup!

To be sure: does AppDomain.CurrentDomain.ProcessExit still fire on SIGTERM?

@jkotas
Copy link
Member Author

jkotas commented May 13, 2025

To be sure: does AppDomain.CurrentDomain.ProcessExit still fire on SIGTERM?

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:

Action<PosixSignalContext> handler = HandlePosixSignal;
_sigIntRegistration = PosixSignalRegistration.Create(PosixSignal.SIGINT, handler);
_sigQuitRegistration = PosixSignalRegistration.Create(PosixSignal.SIGQUIT, handler);
_sigTermRegistration = PosixSignalRegistration.Create(PosixSignal.SIGTERM, handler);
.

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

@jkotas
Copy link
Member Author

jkotas commented May 13, 2025

On Windows, this reverts the behavior to what it used to be in .NET Framework.
On Unix, this reverts the behavior to what it used to be in classic Mono.

@tmds
Copy link
Member

tmds commented May 13, 2025

I'm asking because before PosixSignalRegistration was introduced, AppDomain.CurrentDomain.ProcessExit was the (only) API for setting up a SIGTERM handler.

It's probably worth calling out explicitly in the breaking change doc.

@jkotas jkotas merged commit 91195a7 into dotnet:main May 15, 2025
148 of 152 checks passed
@jkotas jkotas deleted the issue-115206 branch May 15, 2025 20:58
@jkotas
Copy link
Member Author

jkotas commented May 15, 2025

Breaking change issue created: dotnet/docs#46226

@jkotas jkotas changed the title Delete runtime build-in handling for SIGTERM Delete runtime built-in handling for SIGTERM May 16, 2025
jkotas added a commit to dotnet/dotnet that referenced this pull request May 16, 2025
akoeplinger added a commit to dotnet/aspnetcore that referenced this pull request May 22, 2025
jkotas added a commit to dotnet/aspnetcore that referenced this pull request May 22, 2025
jkotas added a commit to dotnet/aspnetcore that referenced this pull request May 22, 2025
jkotas added a commit to dotnet/aspnetcore that referenced this pull request May 22, 2025
wtgodbe pushed a commit to dotnet/aspnetcore that referenced this pull request May 22, 2025
* [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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-PAL-coreclr breaking-change Issue or PR that represents a breaking API or functional change over a prerelease. needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CoreCLR's CNTRL_SHUTDOWN_EVENT handler prevents graceful exit of services during system shutdown
5 participants