Skip to content
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

Ctrl+C kills background git processes on git bash #950

Closed
1 task done
vincepare opened this issue Nov 10, 2016 · 5 comments
Closed
1 task done

Ctrl+C kills background git processes on git bash #950

vincepare opened this issue Nov 10, 2016 · 5 comments
Assignees
Labels
Milestone

Comments

@vincepare
Copy link

vincepare commented Nov 10, 2016

  • 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.10.2.windows.1
sizeof-long: 4
machine: x86
  • 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]

(Windows 7 64-bit)

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

I have no install-options.txt file.
I'm using a portable release : PortableGit-prerelease-2.11.0.rc0.windows.1-32-bit.7z.exe

Details

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

Bash

# Building a test repository
mkdir gitrepo
cd gitrepo
git init
for i in $(seq 1 7); do echo "$(date) : edit : $i" >> dummy.txt; git add .; git commit -m "Commit $i"; done;

# Starting up a git bisect session (to be able to use bisect visualize then)
git bisect start
git bisect bad HEAD
git bisect good HEAD~5

# Launch gitk from git, in background
git bisect visualize &
# Now, press Ctrl+C
  • What did you expect to occur after running these commands?

I expect to keep gitk running, because it is a background process.

  • What actually happened instead?

gitk gets killed by Ctrl+C

Additionnal notes

This is not specific to git bisect visualize, this issue seems to apply on all programs launched from git, such as git difftool (I chose to show git bisect visualize in my example simply because it does not need a custom git configuration, unlike git difftool).

Furthermore, I also tested on linux, without meeting the issue (gitk keeps running).

After a few search on the internet, I suspect the PGID (bash process groups) to be responsible for the issue :

Here are different processes running (after a git bisect visualize &) :

$ ps xao pid,ppid,pgid,sid,command
      PID    PPID    PGID     WINPID   TTY         UID    STIME COMMAND
     5952   11444    5952       9668  cons0    1062335 17:04:22 /usr/bin/ps
    12040    7016   11444      12724  cons0    1062335 17:03:54 /mingw32/bin/wish
    11444       1   11444      11444  cons0    1062335 17:01:59 /usr/bin/bash
I    9096       1    9096       9096  cons0    1062335 10:59:48 /usr/bin/bash
    11336   11444   11336      10272  cons0    1062335 17:03:52 /bin/git
     7016       1   11444       7016  cons0    1062335 17:03:53 /usr/bin/sh

You can see that /mingw32/bin/wish (the process holding gitk) has the same PGID than bash (11444).

The same test on linux shows that the PGID is different :

  PID  PPID  PGID   SID COMMAND
...
 1009     1  1009  1009 /usr/sbin/lightdm
 1049  1009  1049  1049  \_ /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
 1496  1009  1009  1009  \_ lightdm --session-child 12 19
 1819  1496  1819  1819      \_ /sbin/upstart --user
...
 8827  1819  1996  1996          \_ /usr/lib/gnome-terminal/gnome-terminal-server
 8834  8827  8834  8834          |   \_ bash
22163  8827 22163 22163          |   \_ bash
22335 22163 22335 22163          |       \_ git bisect visualize
22336 22335 22335 22163          |       |   \_ /bin/sh /usr/lib/git-core/git-bisect visualize
22350 22336 22335 22163          |       |       \_ wish /usr/bin/gitk -- --bisect --
22376 22163 22376 22163          |       \_ ps xafo pid,ppid,pgid,sid,command
@dscho
Copy link
Member

dscho commented Nov 16, 2016

I fear that there is not a whole lot we can do about this. You see, there is no such thing as a "background process" on Windows. They are all alike. So when we kill a process using Ctrl+C, we have to traverse all of its children, too, in order to kill non-background processes correctly. But of course, as we have no way to discern between background and non-background processes, we just kill 'em all...

@dscho dscho added the bug label Nov 16, 2016
@dscho
Copy link
Member

dscho commented Apr 23, 2018

A fix for this should be an incidental fallout of my upcoming fix for #1491.

@dscho dscho self-assigned this Apr 23, 2018
@dscho dscho added this to the v2.17.0(2) milestone Apr 23, 2018
@dscho
Copy link
Member

dscho commented Apr 23, 2018

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

@dscho dscho closed this as completed Apr 23, 2018
@vincepare
Copy link
Author

The issue is fixed on the latest release (PortableGit-2.20.1-32-bit.7z.exe).

But this doesn't seems to be a fallout of #1491, after testing many releases from https://wingit.blob.core.windows.net/files/index.html, I can tell the first release which fixes the issue is this one :

The previous release still had the bug :

And this is pretty weird because there is so little difference between these two versions, according to git :
d0192a7...4584fb7.

@dscho
Copy link
Member

dscho commented Dec 24, 2018

And this is pretty weird because there is so little difference between these two versions, according to git :
d0192a7...4584fb7.

Please note that Git for Windows consists of more than just the build output for the Git source code. It contains parts of well over 100 packages, among them the MSYS2 runtime that is actually responsible for handling Ctrl+C in Git Bash. If you compare the files /etc/package-versions.txt from those two snapshots, you will learn what else changed (in addition to the Git source code).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants