Git: Ctrl-C terminates background jobs

[orgads]

• [X] I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.13.3.windows.1
built from commit: faaf2320f32f6ac52a69502c6b157b6ea4781f50
sizeof-long: 4
machine: x86_64

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 6.1.7601]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Path Option: Cmd
SSH Option: OpenSSH
CURL Option: WinSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

git gui &
Ctrl-C

• What did you expect to occur after running these commands?

I expect Ctrl-C not to terminate git gui, which runs in the background.

• What actually happened instead?

It does.

[engelux]

My issue is a little different, if i type CTRL-C it seems to kill the service (npm start) but if i see the task manager on windows the process still there

In older versions of git the process kill with out problem typeing CTRL-C

Info:
Microsoft Windows [Version 10.0.15063]

git version 2.13.3.windows.1
built from commit: faaf2320f32f6ac52a69502c6b157b6ea4781f50
sizeof-long: 4
machine: x86_64

Install options

Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

Terminal: Bash

What did you expect to occur after running these commands?
I expect Ctrl-C to terminate nodejs process/service (npm start) process, which runs in the background.

What actually happened instead?
Ctrl-C does not terminate or kill nodejs process/service (npm start)

UPDATED
I download a previous version (2.10.2) and it solves the issue, it seems that and earlier version has the problem

[dscho]

I am not aware of any method to discern background from non-background processes. Maybe this can't be solved...

[orgads]

I don't recall it ever happened to me with previous versions.

[dscho]

I don't recall it ever happened to me with previous versions.

Then the previous versions were buggy; they should always have killed the entire process trees.

[orgads]

Process tree of what? It's running in the _background_.

[dscho]

@orgads a process tree is the tree of processes spawned (directly, or indirectly) from one command. We have a function in our version of the MSYS2 runtime for ages that performs that trick: the kill_process_tree() function. And it is this function that backed Ctrl+C in MinTTY also for ages. That changed recently, as it is now only a fallback option (we try first to inject a thread that executed ExitProcess(), giving the process a chance to clean up after itself).

[mat007]

I'm experiencing an issue similar to the one described by @engelux which appears linked to the one described initialy by @orgads, or should we create a separate issue?

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

git version 2.14.1.windows.1
built from commit: 82d9b3f3b2407b52251620597d4b14933685459d
sizeof-long: 4
machine: x86_64

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

Microsoft Windows [Version 10.0.15063]

• What options did you set as part of the installation? Or did you choose the
  defaults?

Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

cmd.exe /c "netstat"
^C

• What did you expect to occur after running these commands?

netstat should not be running anymore.

• What actually happened instead?

The netstat process is still running and outputting text to the console.
Note that the issue has nothing to do with netstat as the same behaviour can be observed with any executable.
This used to work as expected «before»…

[orgads]

@dscho commented on Aug 30, 2017, 3:12 PM GMT+3:

@orgads a process tree is the tree of processes spawned (directly, or indirectly) from one command. We have a function in our version of the MSYS2 runtime _for ages_ that performs that trick: the kill_process_tree() function. And it is this function that backed Ctrl+C in MinTTY also for ages. That changed recently, as it is now only a fallback option (we try first to inject a thread that executed ExitProcess(), giving the process a chance to clean up after itself).

I know what a process tree, but this has nothing to do with _background jobs_. Killing a process tree is needed when you have for example git -> sh -> wish - all of them are in the foreground. Now when you press Ctrl-C you expect that not only git is killed, but all 3 processes.

But if you run a background job (git gui &), it should never be affected by Ctrl-C! Just like the terminal itself is not terminated by Ctrl-C.

Now I see that this only happens with git gui. If I run gitk & and press Ctrl-C it's _not_ terminated. This is really strange...

[dscho]

Now I see that this only happens with git gui. If I run gitk & and press Ctrl-C it's not terminated. This is really strange...

I think this is due to the fact that git gui calls git.exe, i.e. a MINGW executable, while gitk implicitly calls Bash (an MSYS2 executable, via gitk's shebang line).

[orgads]

I'm not sure. git gc & is not terminated by Ctrl-C.

[zaggino]

Hi, this is quite an issue for me (ctrl+c not killing entire process tree).
I've downgraded to 2.12.2.2 and can confirm that this version works fine.

[dscho]

I've downgraded to 2.12.2.2 and can confirm that this version works fine.

Please understand that this just a workaround and does not address the issue properly. There is a reason why I spent dozens of hours to change the way Git Bash handles Ctrl+C: the previous method might have selected better what processes to kill (or simply failed to kill them), but it also gave plenty of Git users grief because it left spurious index.lock files behind.

My issue is a little different, if i type CTRL-C it seems to kill the service (npm start) but if i see the task manager on windows the process still there

@engelux this is a completely different issue: as you pointed out, your problem is not that background processes are killed, your problem is that some node.js process is not killed. Let's not muddy waters in this ticket. You probably want to head over to https://github.com/git-for-windows/git/issues/1219

@mat007 same goes for you.

Back to the issue. @orgads, do you have any time to work on this? If not, I'll have to try to carve out some time from somewhere. I think the issue may be lying around somewhere close to https://github.com/git-for-windows/msys2-runtime/blob/874e2c8efeed9084cd065cf9ea5c0951f5afca02/winsup/cygwin/exceptions.cc#L1548. I could imagine that there is something in ch_spawn that says that this process is running in the background. Or my hunch is wrong, and it is something completely different.

What is really curious is that the previous Git for Windows versions used a much more aggressive method to kill: git-for-windows/msys2-runtime@a5f3bde3526943465b243894a3551157f6ece21e instead of git-for-windows/msys2-runtime@a034d376b278910ef34d5eac1c7b47f507c5a868 (i.e. TerminateProcess() instead of trying to inject a thread that runs ExitProcess()). Therefore, I am a bit puzzled why the previous method did not kill the background process, while the new method does. (Or maybe there were other changes in Cygwin in the meantime that I missed that could be responsible for this behavior?)

[dscho]

Incidentally, while working on https://github.com/git-for-windows/git/issues/1491, I think I managed to fix this. A new snapshot should be available soon: https://wingit.blob.core.windows.net/files/index.html. After leaving all the hard work to me, maybe you can at least test it?

[orgads]

When is this "soon" coming? :smile:

[dscho]

My, my, you can be pushy. I encountered a bug in the 64-bit -> 32-bit call, and I did not want to force anybody to encounter the same bug, so I spent frantic hours trying to fix it before releasing a new MSYS2 runtime. You're welcome.

The Git for Windows SDK is synchronizing at the moment, after that I can kick off a new snapshot build. That's when "soon" is.

[dscho]

The newest snapshot at https://wingit.blob.core.windows.net/files/index.html should fix this. Please test.

[orgads]

I can confirm this issue is solved. There is another related issue which is not solved by this change though. I thought they were, so never reported it properly. Reported now as https://github.com/git-for-windows/git/issues/1648

Thank you, and sorry for pushing. I just thought you forgot to publish the installer.