Mono does not emit ProcessExit event on SIGTERM. #81093

tmds · 2023-01-24T13:19:08Z

To reproduce:

dotnet new web -o web
cd web
dotnet run

Find the pid of the dotnet run process, and send it SIGTERM from another terminal:

kill -SIGTERM <pid>

With CoreCLR, the application shuts down, and the exit code is 0:

...
info: Microsoft.Hosting.Lifetime[0]
      Application is shutting down...
$ echo $?
0

With Mono, the application keeps running, the dotnet run process gets terminated:

Terminated
$ echo $?
143

The web process is still running, you can send it SIGTERM seperately and it terminates nicely.

info: Microsoft.Hosting.Lifetime[0]
      Application is shutting down...

This difference in behavior is causing one of the source-build smoke tests to fail: dotnet/source-build#3174.

cc @akoeplinger

The text was updated successfully, but these errors were encountered:

akoeplinger · 2023-01-24T14:07:14Z

Hmm it feels more like a dotnet/runtime issue to me given this is a difference between Mono and CoreCLR. Should I move the issue?

tmds · 2023-01-24T14:17:50Z

I was not sure where to create it. It does look like the ASP.NET app responds to SIGTERM appropriately.
You can move it to another repo if you prefer.

dotnet-issue-labeler · 2023-01-24T15:40:11Z

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

akoeplinger · 2023-01-24T15:41:36Z

@lambdageek do you know which area we should assign this to?

lambdageek · 2023-01-24T17:13:31Z

@akoeplinger not sure. AppModel, maybe? Cc @vitek-karas

It will probably come back to mono, but it's not obvious to me why the behavior difference.

jkotas · 2023-01-24T17:18:41Z

It is most likely an issue with Mono-specific SIGTERM handler.

jkotas · 2023-01-24T17:25:14Z

Potential duplicate of #31656

tmds · 2023-02-01T08:19:11Z

I've debugged this issue. Mono doesn't install a signal handler for SIGTERM to emit the AppDomain.CurrentDomain.ProcessExit event.

CoreCLR installs it here:

runtime/src/coreclr/pal/src/exception/signal.cpp

Line 236 in 9e05d33

handle_signal(SIGTERM, sigterm_handler, &g_previous_sigterm);

This event is used by the cli to reap the child processes using its ProcessReaper class.

A simpler reproducer for the issue is:

AppDomain.CurrentDomain.ProcessExit += delegate { Console.WriteLine("Process exit"); };
Thread.Sleep(int.MaxValue);

If you send SIGTERM to this app, with CoreCLR you'll see the message get printed, and with Mono you don't.

tmds · 2023-02-01T08:23:41Z

Potential duplicate of #31656

Yes, it is the same root cause. The SigTermExitCode test depends on ProcessExit being emitted on SIGTERM.

tmds · 2023-02-03T08:03:47Z

SIGTERM works for the ASP.NET/Generic host because it moved from the ProcessExit event to the PosixSignal API in .NET 6.

lambdageek · 2023-02-03T15:20:50Z

attn @SamMonoRT

lambdageek · 2023-02-03T15:50:56Z

So the way this seems to work on coreclr is that there's a background thread that waits for commands, among them "process shutdown". the sigterm signal handler writes a "process shutdown" command. That wakes up the thread and it begins the shutdown of the process. We end up in EEShutDownHelper which calls FinalizerThread::RaiseShutdownEvents() That, in turn, wakes up the finalizer thread and eventually makes it call AppDomain::RaiseExitProcessEvent() which invokes the managed AppContext::OnProcessExit method which finally calls the ProcessExit event handlers.

We already have mono_runtime_fire_process_exit_event (); to invoke the AppContext method, which is called by mono_runtime_try_shutdown (which is invokes, for example when you call Environment.Exit).

I guess the missing bit is to install a signal handler for SIGTERM, have it set some flag and wake the finalizer thread (using mono_gc_finalize_notify which is signal-safe) and have the finalizer thread check for the flag and call mono_runtime_try_shutdown to initiate shutdown. (I'm not sure we need a dedicated command thread in addition to the finalizer thread)

akoeplinger · 2023-02-09T13:32:57Z

We did have a SIGTERM handler in mono/mono which was used for crash reporting functionality, it was removed from dotnet/runtime in 0c90347

nealef · 2023-02-16T04:23:52Z

I have experimented with installing a SIGTERM handler that does what is being suggested above. However, when running web applications the managed code is registering to receive any SIGTERM signals:

243709 [000003ffa6c93d20] rt_sigaction(SIGTERM, {sa_handler=0x3ffa2792010, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, {sa_handler=0x3ffa633c990, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, 8) = 0

The handler at address 0x3ffa633c990 is the one I set up. The new one is set via:

[0x3ffa14f2b70: 0.23275 1] ENTER:c System.Runtime.InteropServices.PosixSignalRegistration:Register (System.Runtime.InteropServices.PosixSignal,System.Action<System.Runtime.InteropServices.PosixSignalContext>)(-4, XX)

where -4 == SIGTERM. This method is found in runtime/src/libraries/System.Private.CoreLib/src/System/Runtime/InteropServices/PosixSignalRegistration.Unix.cs and is facilitated by runtime/src/native/libs/System.Native/pal_signal.c.

The signal handler in that module will process the signal and if there is an existing handler will invoke it as well. Unless it is one of the non-cancelable termination signals:

    // For these signals, the runtime original sa_sigaction/sa_handler will terminate the app.
    // This termination can be canceled using the PosixSignal API.
    // For other signals, we immediately invoke the original handler.
    if (!IsCancelableTerminationSignal(sig))
    {
        struct sigaction* origHandler = OrigActionFor(sig);
        if (!IsSigDfl(origHandler) && !IsSigIgn(origHandler))
        {
            if (IsSaSigInfo(origHandler))
            {
                assert(origHandler->sa_sigaction);
                origHandler->sa_sigaction(sig, siginfo, context);

Where IsCancelableTerminationSignal is:

static bool IsCancelableTerminationSignal(int sig)
{
    return sig == SIGINT ||
           sig == SIGQUIT ||
           sig == SIGTERM;
}

Therefore, our signal handler is skipped and we don't get to do the ProcessExit stuff.

tmds · 2023-02-16T06:08:05Z

Web applications cancel SIGTERM using PosixSignal API (#81093 (comment)).

As a test app you can use something like:

AppDomain.CurrentDomain.ProcessExit += delegate { Console.WriteLine("Process exit"); };
Thread.Sleep(int.MaxValue);

nealef · 2023-02-16T06:42:04Z

Web applications cancel SIGTERM using PosixSignal API (#81093 (comment)).

As a test app you can use something like:
AppDomain.CurrentDomain.ProcessExit += delegate { Console.WriteLine("Process exit"); };
Thread.Sleep(int.MaxValue);

Console App

I am seeing that "Process Exit" message with my patch for the simple console app. I don't see it using the unpatched code.

However, while I see the message the program itself keeps on sleeping:

Hello, World!
[0x3ffabbf2b70: 0.00000 0] ENTER:c System.Threading.Thread:Sleep (int)(2147483647)
Process exit

Web App

I see the "Process Exit" with both patched and unpatched .NET 7. This is the app run on both:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

System.AppDomain.CurrentDomain.ProcessExit += delegate { System.Console.WriteLine("Process exit"); };

app.MapGet("/", () => "Hello World!");

app.Run();

nealef · 2023-02-16T12:03:27Z

I need to revisit the tests as I was inconsistent in sending the signal to the correct process. I'll redo in my morning (UTC+10).

nealef · 2023-02-17T02:47:33Z

Revisited:

Console

Without Patch

Killing dotnet process with SIGTERM

$ dotnet run
Hello, World!
Terminated
$

ps before kill -TERM 210248

neale     210248  210053 29 20:10 pts/1    00:00:02 dotnet run
neale     210268  210248  1 20:10 pts/1    00:00:00 /home/neale/HelloWorld/bin/Debug/net7.0/HelloWorld

ps after:

neale     210268       1  0 20:10 pts/1    00:00:00 /home/neale/HelloWorld/bin/Debug/net7.0/HelloWorld

So an orphaned process but returned to prompt.

With Patch

$ dotnet run
Hello, World!
Process exit

Process(es) don't terminate.

ps before the kill -TERM 250796:

neale     250796  250493 32 19:55 pts/0    00:00:01 dotnet run
neale     250815  250796  1 19:55 pts/0    00:00:00 /home/neale/HelloWorld/bin/Debug/net7.0/HelloWorld

ps after:

neale     250796  250493 10 19:55 pts/0    00:00:01 dotnet run
neale     250815  250796  0 19:55 pts/0    00:00:00 /home/neale/HelloWorld/bin/Debug/net7.0/HelloWorld

Web

Without Patch

$ dotnet run
Building...
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5204
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /home/neale/web
Terminated
$

ps before kill -TERM 21087:

neale     210187  210027 12 20:04 pts/0    00:00:02 dotnet run
neale     210207  210187  2 20:04 pts/0    00:00:00 /home/neale/web/bin/Debug/net7.0/web

ps after:

neale     210207       1  0 20:04 pts/0    00:00:00 /home/neale/web/bin/Debug/net7.0/web

With Patch

$ dotnet run
Adding SIGTERM signal handler: 0x3ff840bc9c0
Building...
Adding SIGTERM signal handler: 0x3ff9f1bc9c0
term_signaled: 0 (0x3ff9f31d258)
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5213
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /home/neale/web
      Application is shutting down...
Process exit

Process(es) don't terminate.

ps before kill -250830:

neale     250830  250737 36 20:00 pts/1    00:00:02 dotnet run
neale     250850  250830  8 20:00 pts/1    00:00:00 /home/neale/web/bin/Debug/net7.0/web

ps after:

neale     250830  250737  1 20:00 pts/1    00:00:02 dotnet run

Further Analysis

If I change the console app to do:

System.Console.WriteLine("Hello, World!");
System.AppDomain.CurrentDomain.ProcessExit += delegate { System.Console.WriteLine("Process exit"); };
while (true) {
        System.Threading.Thread.Sleep(1000);
        System.Console.Write(".");
}

Then after the ProcessExit delegate is run the program continues to print . every second.

If I change it to:

bool terminate = false;
System.Console.WriteLine("Hello, World!");
System.AppDomain.CurrentDomain.ProcessExit += delegate { System.Console.WriteLine("Process exit"); terminate = true; };
while (!terminate) {
        System.Threading.Thread.Sleep(1000);
        System.Console.Write(".");
}

Then the writing of the . stops indicating it exits the loop (and the program presumably) but we never return to the prompt.

The Patch

Here's the patch. The area of concern is where it is invoked in the finalizer thread and whether any further action is required (break? set finished to true? something else?).

--- a/src/mono/mono/metadata/gc.c
+++ b/src/mono/mono/metadata/gc.c
@@ -43,6 +43,7 @@
 #include <mono/utils/mono-os-wait.h>
 #include <mono/utils/mono-lazy-init.h>
 #include <mono/utils/mono-threads-wasm.h>
+#include <mono/metadata/runtime.h>
 #ifndef HOST_WIN32
 #include <pthread.h>
 #endif
@@ -63,6 +64,8 @@ static gboolean gc_disabled;

 static gboolean finalizing_root_domain;

+extern gboolean term_signaled;
+
 gboolean mono_log_finalizers;
 gboolean mono_do_not_finalize;
 static volatile gboolean suspend_finalizers;
@@ -879,6 +882,11 @@ finalizer_thread (gpointer unused)
 	mono_hazard_pointer_install_free_queue_size_callback (hazard_free_queue_is_too_big);

 	while (!finished) {
+
+		/* Just in case we've received a SIGTERM */
+		if (term_signaled)
+			mono_runtime_try_shutdown();
+
 		/* Wait to be notified that there's at least one
 		 * finaliser to run
 		 */
diff --git a/src/mono/mono/mini/mini-posix.c b/src/mono/mono/mini/mini-posix.c
index be8f83d3968..9565f4f6ef8 100644
--- a/src/mono/mono/mini/mini-posix.c
+++ b/src/mono/mono/mini/mini-posix.c
@@ -97,6 +97,8 @@
 #endif
 #include "mono/utils/mono-tls-inline.h"

+gboolean term_signaled = FALSE;
+
 #if defined(HOST_WATCHOS)

 void
@@ -291,6 +293,15 @@ MONO_SIG_HANDLER_FUNC (static, sigquit_signal_handler)
 	mono_chain_signal (MONO_SIG_HANDLER_PARAMS);
 }

+MONO_SIG_HANDLER_FUNC (static, sigterm_signal_handler)
+{
+	term_signaled = TRUE;
+
+	mono_gc_finalize_notify ();
+
+	mono_chain_signal (MONO_SIG_HANDLER_PARAMS);
+}
+
 MONO_SIG_HANDLER_FUNC (static, sigusr2_signal_handler)
 {
 	gboolean enabled = mono_trace_is_enabled ();
@@ -390,6 +401,8 @@ mono_runtime_posix_install_handlers (void)
 	sigaddset (&signal_set, SIGFPE);
 	add_signal_handler (SIGQUIT, sigquit_signal_handler, SA_RESTART);
 	sigaddset (&signal_set, SIGQUIT);
+	add_signal_handler (SIGTERM, sigterm_signal_handler, SA_RESTART);
+	sigaddset (&signal_set, SIGTERM);
 	add_signal_handler (SIGILL, mono_crashing_signal_handler, 0);
 	sigaddset (&signal_set, SIGILL);
 	add_signal_handler (SIGBUS, mono_sigsegv_signal_handler, 0);

tmds · 2023-02-21T09:31:56Z

However, while I see the message the program itself keeps on sleeping:

Then after the ProcessExit delegate is run the program continues to print . every second.

CoreCLR doesn't wait for Main to return, it calls exit once it finishes the 'shutdown'.

nealef · 2023-02-22T00:14:37Z

However, while I see the message the program itself keeps on sleeping:

Then after the ProcessExit delegate is run the program continues to print . every second.

CoreCLR doesn't wait for Main to return, it calls exit once it finishes the 'shutdown'.

That does the trick for mono as well. Both the dotnet run and HelloWorld or web processes disappear but (and this happened for earlier test runs there is a process that does stick around).

Before SIGTERM

neale     281002  280568 11 19:07 pts/0    00:00:02 dotnet run
neale     281021  281002 14 19:07 pts/0    00:00:02 /opt/dotnet/dotnet exec /opt/dotnet/sdk/7.0.100/Roslyn/bincore/VBCSCompiler.dll -pipename:5IDRdGpQgCgKll8cx2UPZQl
neale     281035  281002  2 19:07 pts/0    00:00:00 /home/neale/web/bin/Debug/net7.0/web

After SIGTERM

neale     281021       1  7 19:07 pts/0    00:00:02 /opt/dotnet/dotnet exec /opt/dotnet/sdk/7.0.100/Roslyn/bincore/VBCSCompiler.dll -pipename:5IDRdGpQgCgKll8cx2UPZQl

I instrumented the mono process to show the variable being set and the shutdown taking effect:

$ dotnet run
Adding SIGTERM signal handler: 0x3ff8113c9d0
term_signaled: 0 (0x3ff8129d258)
:
term_signaled: 0 (0x3ff8129d258)
Adding SIGTERM signal handler: 0x3ffbbebc9d0
term_signaled: 0 (0x3ffbc01d258)
Hello, World!
...................
term_signaled: 0 (0x3ff8129d258)
:
...................sigterm_signal_handler:299
term_signaled: 1 (0x3ff8129d258)
mono_runtime_fire_process_exit_event:70 - procexit_method: 0x3ff3cbf28e8 - System.AppContext:OnProcessExit
sigterm_signal_handler:299
term_signaled: 1 (0x3ffbc01d258)
mono_runtime_fire_process_exit_event:70 - procexit_method: 0x2aa17a28b58 - System.AppContext:OnProcessExit
Process exit
$

The patch to gc.c now looks like:

@@ -879,6 +882,14 @@ finalizer_thread (gpointer unused)
        mono_hazard_pointer_install_free_queue_size_callback (hazard_free_queue_is_too_big);

        while (!finished) {
+
+               /* Just in case we've received a SIGTERM */
+printf("term_signaled: %d (%p)\n",term_signaled,&term_signaled);
+               if (term_signaled) {
+                       mono_runtime_try_shutdown();
+                       exit(0);
+               }
+
                /* Wait to be notified that there's at least one
                 * finaliser to run
                 */

Is a status of 0 what we want?

tmds · 2023-02-22T03:00:04Z

Is a status of 0 what we want?

On SIGTERM, the exit code should be 128 + SIGTERM.
It can still be changed by the user by setting Environment.ExitCode.

This behavior is captured by the SigTermExitCode test which is currently disabled on Mono.

nealef · 2023-02-23T06:58:26Z

Updated the patch so that we:

+		if (term_signaled) {
+			int ec = mono_environment_exitcode_get();
+			mono_runtime_try_shutdown();
+			if (ec == 0)
+				exit(128+SIGTERM);
+			else
+				exit(ec);
+		}

Now when I send a SIGTERM I see:

$ bash -c "dotnet run;echo $?"
Building...
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5213
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /home/neale/web
info: Microsoft.Hosting.Lifetime[0]
      Application is shutting down...
Process exit
143

Strangely, with the HelloWorld test:

$ bash -c "dotnet run;echo $?"
Hello, World!
..................Process exit
0

tmds · 2023-02-23T07:38:27Z

Updated the patch so that we:

A user should still be able to set the ExitCode, as tested by this case:

runtime/src/libraries/System.Runtime/tests/System/ExitCodeTests.Unix.cs

Line 22 in db21974

[InlineData(42)]

nealef · 2023-02-23T08:08:21Z

Mono has a mono_environment_exitcode_set which gets used by managed code for its Environment.Exitcode set. I think that's in Environment.Mono.cs or similar (I am away from my desk at the moment so have to rely on a faulty memory).

nealef · 2023-02-24T04:23:26Z

The HelloWorld process is exiting with the correct value:

neale     294347  294344 25 23:01 pts/0    00:00:02 dotnet run
neale     294366  294347  1 23:01 pts/0    00:00:00 /home/neale/HelloWorld/bin/Debug/net7.0/HelloWorld

$ kill -TERM 294347

An strace shows all the processes exiting with the desired value:

294366 +++ exited with 143 +++
294347 +++ exited with 143 +++

I changed the HelloWorld program to do:

System.Environment.ExitCode = 181;

And ran things again and this time looked at all the threads:

$ ps -u neale -wLf
neale     294552  294549  294552  4   16 23:18 pts/0    00:00:00 dotnet run
neale     294552  294549  294553  0   16 23:18 pts/0    00:00:00 dotnet run
neale     294552  294549  294554  0   16 23:18 pts/0    00:00:00 dotnet run
neale     294552  294549  294555  0   16 23:18 pts/0    00:00:00 dotnet run
neale     294552  294549  294556  0   16 23:18 pts/0    00:00:00 dotnet run
neale     294552  294549  294557  0   16 23:18 pts/0    00:00:00 dotnet run
neale     294552  294549  294558  0   16 23:18 pts/0    00:00:00 dotnet run
neale     294552  294549  294559  0   16 23:18 pts/0    00:00:00 dotnet run
neale     294552  294549  294562  0   16 23:18 pts/0    00:00:00 dotnet run
neale     294552  294549  294564  0   16 23:18 pts/0    00:00:00 dotnet run
neale     294552  294549  294565  6   16 23:18 pts/0    00:00:00 dotnet run
neale     294552  294549  294566  0   16 23:18 pts/0    00:00:00 dotnet run
neale     294552  294549  294567  0   16 23:18 pts/0    00:00:00 dotnet run
neale     294552  294549  294568  0   16 23:18 pts/0    00:00:00 dotnet run
neale     294552  294549  294569  2   16 23:18 pts/0    00:00:00 dotnet run
neale     294552  294549  294570  0   16 23:18 pts/0    00:00:00 dotnet run
neale     294571  294552  294571  0    5 23:18 pts/0    00:00:00 /home/neale/HelloWorld/bin/Debug/net7.0/HelloWorld
neale     294571  294552  294572  0    5 23:18 pts/0    00:00:00 /home/neale/HelloWorld/bin/Debug/net7.0/HelloWorld
neale     294571  294552  294573  0    5 23:18 pts/0    00:00:00 /home/neale/HelloWorld/bin/Debug/net7.0/HelloWorld
neale     294571  294552  294574  0    5 23:18 pts/0    00:00:00 /home/neale/HelloWorld/bin/Debug/net7.0/HelloWorld
neale     294571  294552  294575  0    5 23:18 pts/0    00:00:00 /home/neale/HelloWorld/bin/Debug/net7.0/HelloWorld
:
$ kill -TERM 294552
:
Hello, World!
..............................sigterm_signal_handler:300 - 294552 triggered
finalizer_thread:889 - 294552 fielded - ec: 0
sigterm_signal_handler:300 - 294571 triggered
finalizer_thread:889 - 294571 fielded - ec: 181
Process exit

The strace showed:

294574 exit_group(181)                  = ?
294574 +++ exited with 181 +++
294573 +++ exited with 181 +++
294572 +++ exited with 181 +++
294575 +++ exited with 181 +++
294571 +++ exited with 181 +++
294555 exit_group(143 <unfinished ...>
294555 <... exit_group resumed>)        = ?
294579 +++ exited with 143 +++
294570 +++ exited with 143 +++
294569 +++ exited with 143 +++
294567 +++ exited with 143 +++
294566 +++ exited with 143 +++
294565 +++ exited with 143 +++
294564 +++ exited with 143 +++
294562 +++ exited with 143 +++
294558 +++ exited with 143 +++
294557 +++ exited with 143 +++
294555 +++ exited with 143 +++
294554 +++ exited with 143 +++
294553 +++ exited with 143 +++
294552 +++ exited with 143 +++

So I think it's doing what it should. Should I generate a PR?

akoeplinger · 2023-02-24T16:41:22Z

The VBCSCompiler sticking around is expected, it's the Roslyn compiler server: https://github.com/dotnet/roslyn/blob/main/docs/compilers/Compiler%20Server.md.

This is probably because you use dotnet run which does a build first. If you launch the app directly it shouldn't happen.

tmds · 2023-02-28T12:45:04Z

So I think it's doing what it should. Should I generate a PR?

@nealef definitely!

"Mono does not emit ProcessExit event on SIGTERM" * src/mono/mono/mini/mini-posix.c - Add signal handler for SIGTERM - SIGTERM handler will set a global variable that may be monitored by the GC finalizer thread * src/mono/mono/metadata/gc.c - Monitor for sigterm and kick off the shutdown process when encountered by calling mono_runtime_try_shutdown(). - Exit with either the user set exitcode (System.Environment.ExitCode) or SIGTERM + 128.

…on SIGTERM" * src/mono/mono/mini/mini-posix.c - Add signal handler for SIGTERM * src/mono/mono/mini/mini-windows.c - Add signal handler for SIGTERM * src/mono/mono/mini/mini-runtime.c - Add mono_sigterm_signal_handler to process SIGTERM that will set a global variable to be monitored by the GC finalizer thread * src/mono/mono/mini/mini-runtime.h - Define prototype for mono_sigterm_signal_handler() * src/mono/mono/metadata/gc.c - Monitor for sigterm and kick off the shutdown process when encountered by calling mono_runtime_try_shutdown(). - Exit with either the user set exitcode (System.Environment.ExitCode) or SIGTERM + 128.

SamMonoRT · 2023-07-31T15:44:16Z

@nealef - your PR addresses the issue, should we close this one ?

nealef · 2023-08-01T10:05:17Z

It doesn't address it for Windows. I am attempting to mimic the behaviour of coreCLR but haven't had enough free cycles to get it done.

SamMonoRT · 2023-08-11T23:22:44Z

Moving this to the 9.0.0 milestone. If the fix is trivial and non-risky we will consider backport to 8.0 build prior to release.

…on SIGTERM" * src/mono/mono/mini/mini-posix.c - Add signal handler for SIGTERM * src/mono/mono/mini/mini-windows.c - Add signal handler for SIGTERM - Use the correct signal for handler * src/mono/mono/mini/mini-runtime.c - Add mono_sigterm_signal_handler to process SIGTERM that will set a global variable to be monitored by the GC finalizer thread - Set a default exit code before setting the term_signaled variable that gets checked in gc * src/mono/mono/mini/mini-runtime.h - Define prototype for mono_sigterm_signal_handler() * src/mono/mono/metadata/gc.c - Monitor for sigterm and kick off the shutdown process when encountered by calling mono_runtime_try_shutdown(). - Exit with either the user set exitcode (System.Environment.ExitCode) or SIGTERM + 128. - Simplify use of exit code now that a default is being set - Rename term_signaled to match mono style - Remove volatile attribute - Move testing of shutdown until after the sem wait * src/libraries/System.Runtime/tests/System/ExitCodeTests.Unix.cs - Re-enable ExitCodeTests for mono * src/mono/mono/mini/exceptions-amd64.c src/mono/mono/mini/exceptions-x86.c - Add control event handling for windows

…TERM" (#100056) * src/mono/mono/mini/mini-posix.c - Add signal handler for SIGTERM * src/mono/mono/mini/mini-windows.c - Add signal handler for SIGTERM - Use the correct signal for handler * src/mono/mono/mini/mini-runtime.c - Add mono_sigterm_signal_handler to process SIGTERM that will set a global variable to be monitored by the GC finalizer thread - Set a default exit code before setting the term_signaled variable that gets checked in gc * src/mono/mono/mini/mini-runtime.h - Define prototype for mono_sigterm_signal_handler() * src/mono/mono/metadata/gc.c - Monitor for sigterm and kick off the shutdown process when encountered by calling mono_runtime_try_shutdown(). - Exit with either the user set exitcode (System.Environment.ExitCode) or SIGTERM + 128. - Simplify use of exit code now that a default is being set - Rename term_signaled to match mono style - Remove volatile attribute - Move testing of shutdown until after the sem wait * src/libraries/System.Runtime/tests/System/ExitCodeTests.Unix.cs - Re-enable ExitCodeTests for mono * src/mono/mono/mini/exceptions-amd64.c src/mono/mono/mini/exceptions-x86.c - Add control event handling for windows Co-authored-by: Jo Shields <directhex@apebox.org>

dotnet-issue-labeler bot added the untriaged New issue has not been triaged by the area owner label Jan 24, 2023

This was referenced Jan 24, 2023

Check for Mono runtime #81076

Closed

tests: ExecuteRunWeb: update expected SIGTERM exit code on mono. dotnet/dotnet#19

Closed

akoeplinger transferred this issue from dotnet/sdk Jan 24, 2023

lambdageek added the area-VM-meta-mono label Jan 24, 2023

tmds mentioned this issue Jan 25, 2023

tests: ExecuteRunWeb: update expected SIGTERM exit code on mono. dotnet/installer#15341

Merged

tmds changed the title ~~'dotnet run' behaves different on SIGTERM with Mono compared to CoreCLR~~ Mono does not emit ProcessExit event on SIGTERM. Feb 1, 2023

lambdageek added this to the 8.0.0 milestone Feb 8, 2023

lambdageek removed the untriaged New issue has not been triaged by the area owner label Feb 8, 2023

nealef mentioned this issue Mar 1, 2023

Enable mono runtime to handle SIGTERM like CoreCLR #82806

Closed

nealef mentioned this issue Mar 1, 2023

Enable mono runtime to handle SIGTERM like CoreCLR #82806 #82813

Closed

MichaelSimons mentioned this issue Jun 1, 2023

WebScenarioTests smoke tests fail on mono with unexpected exit code. dotnet/source-build#3174

Closed

SamMonoRT modified the milestones: 8.0.0, 9.0.0 Aug 11, 2023

steveisok closed this as completed Jul 12, 2024

akoeplinger mentioned this issue Jul 17, 2024

Provide fix for #81093 - "Mono does not emit ProcessExit event on SIGTERM" #100056

Merged

dotnet-policy-service bot added the in-pr There is an active PR which will close this issue when it is merged label Jul 17, 2024

github-actions bot locked and limited conversation to collaborators Aug 17, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Mono does not emit ProcessExit event on SIGTERM. #81093

Mono does not emit ProcessExit event on SIGTERM. #81093

tmds commented Jan 24, 2023

akoeplinger commented Jan 24, 2023

tmds commented Jan 24, 2023

dotnet-issue-labeler bot commented Jan 24, 2023

akoeplinger commented Jan 24, 2023

lambdageek commented Jan 24, 2023

jkotas commented Jan 24, 2023

jkotas commented Jan 24, 2023

tmds commented Feb 1, 2023

tmds commented Feb 1, 2023

tmds commented Feb 3, 2023

lambdageek commented Feb 3, 2023

lambdageek commented Feb 3, 2023 •

edited

Loading

akoeplinger commented Feb 9, 2023

nealef commented Feb 16, 2023

tmds commented Feb 16, 2023

nealef commented Feb 16, 2023

nealef commented Feb 16, 2023

nealef commented Feb 17, 2023

tmds commented Feb 21, 2023

nealef commented Feb 22, 2023

tmds commented Feb 22, 2023

nealef commented Feb 23, 2023 •

edited

Loading

tmds commented Feb 23, 2023

nealef commented Feb 23, 2023

nealef commented Feb 24, 2023

akoeplinger commented Feb 24, 2023 •

edited

Loading

tmds commented Feb 28, 2023

SamMonoRT commented Jul 31, 2023

nealef commented Aug 1, 2023 via email

SamMonoRT commented Aug 11, 2023

Mono does not emit ProcessExit event on SIGTERM. #81093

Mono does not emit ProcessExit event on SIGTERM. #81093

Comments

tmds commented Jan 24, 2023

akoeplinger commented Jan 24, 2023

tmds commented Jan 24, 2023

dotnet-issue-labeler bot commented Jan 24, 2023

akoeplinger commented Jan 24, 2023

lambdageek commented Jan 24, 2023

jkotas commented Jan 24, 2023

jkotas commented Jan 24, 2023

tmds commented Feb 1, 2023

tmds commented Feb 1, 2023

tmds commented Feb 3, 2023

lambdageek commented Feb 3, 2023

lambdageek commented Feb 3, 2023 • edited Loading

akoeplinger commented Feb 9, 2023

nealef commented Feb 16, 2023

tmds commented Feb 16, 2023

nealef commented Feb 16, 2023

Console App

Web App

nealef commented Feb 16, 2023

nealef commented Feb 17, 2023

Console

Without Patch

With Patch

Web

Without Patch

With Patch

Further Analysis

The Patch

tmds commented Feb 21, 2023

nealef commented Feb 22, 2023

Before SIGTERM

After SIGTERM

tmds commented Feb 22, 2023

nealef commented Feb 23, 2023 • edited Loading

tmds commented Feb 23, 2023

nealef commented Feb 23, 2023

nealef commented Feb 24, 2023

akoeplinger commented Feb 24, 2023 • edited Loading

tmds commented Feb 28, 2023

SamMonoRT commented Jul 31, 2023

nealef commented Aug 1, 2023 via email

SamMonoRT commented Aug 11, 2023

lambdageek commented Feb 3, 2023 •

edited

Loading

nealef commented Feb 23, 2023 •

edited

Loading

akoeplinger commented Feb 24, 2023 •

edited

Loading