Note that we don't really re-throw the signal to the child, but rather run cleanupProcess, which runs terminateProcess, which runs:

• on unix: https://github.com/haskell/process/blob/e448450049ac51a6fcd5d1f0be86448d0931d71a/cbits/posix/runProcess.c#L199-L203 (equivalent to SIGTERM)
• on windows: https://github.com/haskell/process/blob/master/cbits/win32/runProcess.c#L467-L494 (this runs TerminateProcess)

So I tracked down the callstack for the downloaders that invoke curl etc... and it seems they also invoke rawSystemStdInOut asynchronously via withAsync. I assume we won't really kill all curl processes that way?

Another possibility is to do it like rio:

https://hackage.haskell.org/package/rio-0.1.21.0/docs/src/RIO.Process.html#exec

-- | Execute a process within the configured environment.
--
-- Execution will not return, because either:
--
-- 1) On non-windows, execution is taken over by execv of the
-- sub-process. This allows signals to be propagated (#527)
--
-- 2) On windows, an 'ExitCode' exception will be thrown.
--
-- @since 0.0.3.0
exec :: (HasProcessContext env, HasLogFunc env) => String -> [String] -> RIO env b
#ifdef WINDOWS
exec = execSpawn
#else
exec cmd0 args = do
    wd <- view workingDirL
    envStringsL <- view envVarsStringsL
    cmd <- preProcess cmd0
    withProcessTimeLog wd cmd args $ liftIO $ do
      for_ wd setCurrentDirectory
      executeFile cmd True args $ Just envStringsL
#endif

But this seems to me it would only work nicely on unix.

Very much in favour of doing something here! I think cabal should ensure all its children exit on SIGTERM.

Some vague thoughts:

• I agree that for run and exec, exec(3)-like behavior would be ideal. It also seems like it would be worthwhile fixing run/exec first if that's easier.
• Regarding the lack of clean-up, I'm also a bit unsure what it means to keep all of these handlers around. I imagine we might run into issues such as running out of file descriptors keeping all those fd handles around? I think multiple signal handlers don't work -- previous signal handlers are replaced by newer ones -- which would make this sort of work accidentally.
• I'm wondering whether we could do something like:
  • install SIGTERM handler that swallows the signal and throws an async exception at the main thread (not exactly sure whether that's sensible and can be achieved)
  • bracket the createProcess calls with cleanupProcess
    EDIT: proof of concept PR: Handle SIGTERM properly, on unix systems #7921