"uv tool run" swallows SIGINT without forwarding to the underlying process

[gibsondan]

Summary

To repro:

• run:

uv tool run --with dagster-webserver dagster dev --empty-workspace

Leave it running.

• Find the pid of the process that is running using ps aux

• Run:

kill -2 <that pid>

• See no reaction from the process even though it is set up to handle SIGINTs.

• Running the same command out of uv, like so:

dagster dev --empty-workspace

Results in a process that can be cleanly interrupted using 'kill -2'.

I see a similar issue for uv run: #6724 - but nothing for uv tool run.

Platform

Darwin 23.6.0 arm64

Version

uv 0.6.5 (bcbcd0a 2025-03-06)

Python version

Python 3.11.9

[gibsondan]

SIGTERM (kill -15) seems to work, interestingly.

[zanieb]

See

uv/crates/uv/src/commands/run.rs

Lines 11 to 24 in e7fc05e

	// On Unix, shells will send SIGINT to the active process group when a user presses `Ctrl-C`. In
	// general, this means that uv should ignore SIGINT, allowing the child process to cleanly exit
	// instead. If uv forwarded the SIGINT immediately, the child process would receive _two_ SIGINT
	// signals which has semantic meaning for some programs, i.e., slow exit on the first signal and
	// fast exit on the second. The exception to this is if a child process changes its process
	// group, in which case the shell will _not_ send SIGINT to the child process and uv must take
	// ownership of forwarding the signal.
	//
	// Note this assumes an interactive shell. If a signal is sent directly to the uv parent process
	// (e.g., `kill -2 <pid>`), the process group is not involved and a signal is not sent to the
	// child by default. In this context, uv must forward the signal to the child. We work around
	// this by forwarding SIGINT if it is received more than once. We could attempt to infer if the
	// parent is a shell using TTY detection(?), but there hasn't been sufficient motivation to
	// explore alternatives yet.

• Improve SIGINT handling in uv run #11009

This is "intentional" right now. It'd be helpful to hear more about the motivating use-case.

[gibsondan]

We have a CLI command that programatically launches "uv tool run" in a subprocess and then tries to terminate it when the process is terminated. When running in the terminal, CTRL-C works fine. When testing the command in CI/CD, there's no CTRL-C equivalent, so the command hangs forever.

I've run into the problem described into that comment myself and agree that it's very annoying that you can't tell the terminal not to send CTRL-C to subprocesses.

[zanieb]

Yeah I'm not sure what to do here, other than suggest SIGINT twice or SIGTERM.

We could add TTY detection and toggle based on that? I'm not sure if that will be reliable, I'd have to give it a try.

[bulletmark]

If I run marimo, e.g. marimo tutorial intro, then I can stop it easily by typing ctrl+c twice quickly, once to initiate termination and another to not bother answering the subsequent Are you sure you want to quit? (y/n) prompt.

However, if I run uvx marimo tutorial intro then the second cntl+c just hangs and I have to kill the uv tool process manually which I am guessing is related to this issue?

Edit: to be clear, I am guessing the second ctrl+c is not being passed on?

[zanieb]

Huh

DEBUG Spawned child 3116 in process group 2547

        Edit intro.py in your browser 📝

        ➜  URL: http://localhost:2718?access_token=WjuwVKsg1OgPkqRq0Eo0CA

^CDEBUG Received SIGINT, assuming the child received it as part of the process group
        Are you sure you want to quit? (y/n): 
DEBUG Received SIGINT, forwarding to child at 3116
DEBUG Received SIGINT, forwarding to child at 3116

Aborted!
^CDEBUG Received SIGINT, forwarding to child at 3116
^CDEBUG Received SIGINT, forwarding to child at 3116
^CDEBUG Received SIGINT, forwarding to child at 3116
^CDEBUG Received SIGINT, forwarding to child at 3116
^CDEBUG Received SIGINT, forwarding to child at 3116

This seems like it might be a problem with marimo? Even if I do kill -2 3116 it doesn't exit. I have to kill -9 the marimo process. I don't see anything obvious in their code though https://github.com/marimo-team/marimo/blob/984af117b0ec03f8f314eb571b77182f0c17fe8a/marimo/_server/api/interrupt.py#L44-L75

With their development mode, I can see a little more logs..

^CDEBUG Received SIGINT, assuming the child received it as part of the process group
        Are you sure you want to quit? (y/n): DEBUG Received SIGINT, forwarding to child at 27319
DEBUG Received SIGINT, forwarding to child at 27319
INFO:     connection closed
[D 250322 21:48:00 ws:735] Websocket terminated with CancelledError
[D 250322 21:48:00 auth:37] Validating auth
INFO:     127.0.0.1:58565 - "GET /api/usage HTTP/1.1" 200 OK

Aborted!
^CDEBUG Received SIGINT, forwarding to child at 27319

But it's still not clear where it's blocked. So.. a debugger I guess?

❯ lldb -p 39324
(lldb) process attach --pid 39324
Process 39324 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x000000019bdb0440 libsystem_kernel.dylib`__wait4 + 8
libsystem_kernel.dylib`__wait4:
->  0x19bdb0440 <+8>:  b.lo   0x19bdb0460    ; <+40>
    0x19bdb0444 <+12>: pacibsp 
    0x19bdb0448 <+16>: stp    x29, x30, [sp, #-0x10]!
    0x19bdb044c <+20>: mov    x29, sp
Executable module set to "/Users/zb/.local/share/uv/python/cpython-3.13.0-macos-aarch64-none/bin/python3.13".
Architecture set to: arm64-apple-macosx-.
(lldb) l
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x000000019bdb0440 libsystem_kernel.dylib`__wait4 + 8
    frame #1: 0x0000000101af40e8 libpython3.13.dylib`os_waitpid + 92
    frame #2: 0x00000001019708ec libpython3.13.dylib`_PyEval_EvalFrameDefault + 48020
    frame #3: 0x0000000101aad01c libpython3.13.dylib`atexit_callfuncs.llvm.15780486606463704554 + 100
    frame #4: 0x0000000101ad3110 libpython3.13.dylib`_Py_Finalize.llvm.7324148869256557854 + 176
    frame #5: 0x0000000101b2409c libpython3.13.dylib`Py_Exit + 64
    frame #6: 0x0000000101b23ffc libpython3.13.dylib`handle_system_exit + 32
    frame #7: 0x0000000101b23ca0 libpython3.13.dylib`_PyErr_PrintEx.llvm.1117032873449786082 + 52
    frame #8: 0x0000000101b42ff8 libpython3.13.dylib`_PyRun_SimpleFileObject + 416
    frame #9: 0x0000000101b42b64 libpython3.13.dylib`_PyRun_AnyFileObject + 80
    frame #10: 0x0000000101b4216c libpython3.13.dylib`pymain_run_file_obj + 164
    frame #11: 0x0000000101b41fb8 libpython3.13.dylib`pymain_run_file + 72
    frame #12: 0x0000000101b4094c libpython3.13.dylib`Py_RunMain + 956
    frame #13: 0x0000000101b403d4 libpython3.13.dylib`pymain_main + 468
    frame #14: 0x0000000101b401f4 libpython3.13.dylib`Py_BytesMain + 40
    frame #15: 0x000000019ba5f154 dyld`start + 2476
(lldb) thread list
Process 39324 stopped
* thread #1: tid = 0x35c4149, 0x000000019bdb0440 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
(lldb) q
Quitting LLDB will detach from one or more processes. Do you really want to proceed: [Y/n] y

So it does appear to be exiting. os_waitpid is suspicious. Let's kill the children...

❯ pstree 39323
-+= 39323 zb /Users/zb/.cargo/bin/uv tool uvx --offline -vv marimo tutorial intro
 \-+- 39324 zb /Users/zb/.cache/uv/archive-v0/b-WyXMaqxa_OUjxyhedhR/bin/python /Users/zb/.cache/uv/archive-v0
   |--= 39398 zb /Users/zb/.cache/uv/archive-v0/b-WyXMaqxa_OUjxyhedhR/bin/python -c from multiprocessing.spaw
   \--- 39397 zb /Users/zb/.cache/uv/archive-v0/b-WyXMaqxa_OUjxyhedhR/bin/python -c from multiprocessing.reso
❯ kill 39397 39398

Now it exits

^CDEBUG Received SIGINT, assuming the child received it as part of the process group
        Are you sure you want to quit? (y/n): DEBUG Received SIGINT, forwarding to child at 39324
DEBUG Received SIGINT, forwarding to child at 39324

Aborted!
DEBUG Command exited with code: 1

I suspect they're not cleaning up these children

FWIW Ctrl-C then Ctrl-D works for me.

[bulletmark]

Thanks zanieb. ctrl-c + ctrl-d does work but is slightly less convenient then two ctrl-c's in a row and somewhat side-steps the issue because it avoids the 2nd interrupt. I will raise a bug on marimo but can you first comment on why/how this could work when done in marimo normally, and only fails when run under uv?

[zanieb]

I don't know. My best guess is that it's something like...

When you use marimo directly and press Ctrl-C, the shell sends a SIGINT to the process group. Marimo captures this, and when sent again, it exits.

When you use uv, the shell sends a SIGINT to the process group — uv ignores it since the shell has sent it to Marimo as part of the process group. When you press Ctrl-C again, the same thing happens — but uv sees this repeated attempt and forwards the SIGINT as well. Now, Marimo receives a third SIGINT which breaks its interrupt handler?

You can actually test this theory by bumping our SIGINT forwarding count...

diff --git a/crates/uv/src/commands/run.rs b/crates/uv/src/commands/run.rs
index 8aaa31b56..a26d25012 100644
--- a/crates/uv/src/commands/run.rs
+++ b/crates/uv/src/commands/run.rs
@@ -100,7 +100,7 @@ pub(crate) async fn run_to_completion(mut handle: Child) -> anyhow::Result<ExitS
                     // If the pgid _differs_ from the parent, the child will not receive a SIGINT
                     // and we should forward it. If we've received multiple SIGINTs, forward it
                     // regardless.
-                    if child_pgid == parent_pgid && sigint_count < 2 {
+                    if child_pgid == parent_pgid && sigint_count < 5 {
                         debug!("Received SIGINT, assuming the child received it as part of the process group");
                         continue;
                     }

With this, Marimo consistently exits as I would expect. Interestingly changing it to < 3 doesn't work because the second Ctrl-C appears to send multiple signals (on my shell)

e.g., this is two Ctrl-C sends

DEBUG Spawned child 35957 in process group 35922

        Edit intro.py in your browser 📝

        ➜  URL: http://localhost:2719?access_token=dpcjotKtPa4AvK_kZQsauw

        Are you sure you want to quit? (y/n): 
DEBUG Received SIGINT, assuming the child received it as part of the process group
DEBUG Received SIGINT, assuming the child received it as part of the process group
DEBUG Received SIGINT, assuming the child received it as part of the process group

ERROR:    Cancel 0 running task(s), timeout graceful shutdown exceeded

        Thanks for using marimo! 🌊🍃

DEBUG Command exited with code: 0

[zanieb]

It's hard to say what we could do to improve this here, since there is an expectation that we will forward the signal eventually — otherwise it will never be received if the parent is not a shell. Regardless, the main problem is that when Marimo receives multiple interrupts during shutdown it can get stuck waiting for its children.