CTRL-C during SSH causes delayed interrupt of SSH process as well as sending SIGINT to remote process

[macdjord]

• 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.36.1.windows.1
cpu: x86_64
built from commit: e2ff68a2d1426758c78d023f863bfa1e03cbc768
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

• 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 10.0.19044.1645]

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

$ cat /etc/install-options.txt

Editor Option: Notepad++
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: LFOnly
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Enabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

No

Details

When running an SSH command, hitting CTRL-C sends SIGINT to the remote process instead of terminating the SSH command, as expected. However, in 2.36.1.windows.1, if you sent at least one CTRL-C during an SSH session, then, once the SSH session ends but before the SSH command terminates, the SSH command will receive an interrupt:

REDACTED@REDACTED MINGW64 ~
$ ssh dev
Last login: Tue May 10 16:42:30 2022 from 10.0.132.5

[foo@bar-dev-12 ~  DEV12 ]
 $ ^C
[foo@bar-dev-12 ~  DEV12 ]
 $ ^C
[foo@bar-dev-12 ~  DEV12 ]
 $
[foo@bar-dev-12 ~  DEV12 ]
 $ exit
logout
Connection to 10.0.25.209 closed.
Traceback (most recent call last):
  File "C:/Users/REDACTED/source/ssh-wrappy.git/bin/ssh", line 358, in <module>
    res = main()
  File "C:/Users/REDACTED/source/ssh-wrappy.git/bin/ssh", line 350, in main
    ret = subprocess.call(cmd)
  File "C:\Users\REDACTED\AppData\Local\Programs\Python\Python37\lib\subprocess.py", line 325, in call
    return p.wait(timeout=timeout)
  File "C:\Users\REDACTED\AppData\Local\Programs\Python\Python37\lib\subprocess.py", line 990, in wait
    return self._wait(timeout=timeout)
  File "C:\Users\REDACTED\AppData\Local\Programs\Python\Python37\lib\subprocess.py", line 1230, in _wait
    timeout_millis)
KeyboardInterrupt

REDACTED@REDACTED MINGW64 ~
$ echo $?
1

Note: ssh-wrappy.git/bin/ssh is a Python wrapper around ssh.exe which we use to automatically translate certain server names into their addresses. dev, however, is not one of those special servers.

If CTRL-C is not used during the SSH session, it terminates cleanly instead:

REDACTED@REDACTED MINGW64 ~
$ ssh dev
Last login: Tue May 10 16:42:59 2022 from 10.0.132.5

[foo@bar-dev-12 ~  DEV12 ]
 $ exit
logout
Connection to 10.0.25.209 closed.

REDACTED@REDACTED MINGW64 ~
$ echo $?
0

If I bypass the wrapper script, the same thing happens, just less obviously without Python's exception traceback:

REDACTED@REDACTED MINGW64 ~
$ /bin/ssh dev
Last login: Tue May 10 16:46:01 2022 from 10.0.132.5

[foo@bar-dev-12 ~  DEV12 ]
 $ ^C
[foo@bar-dev-12 ~  DEV12 ]
 $ exit
logout
Connection to 10.0.25.209 closed.

REDACTED@REDACTED MINGW64 ~
$ echo $?
130

REDACTED@REDACTED MINGW64 ~
$ /bin/ssh dev
Last login: Tue May 10 16:50:21 2022 from 10.0.132.5

[foo@bar-dev-12 ~  DEV12 ]
 $ exit
logout
Connection to 10.0.25.209 closed.

REDACTED@REDACTED MINGW64 ~
$ echo $?
0

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

CTRL-C sent to SSH should affect only the remote command.

• What actually happened instead?

CTRL-C affected both the remote command & the SSH command.

Notes

• 2.34.1 behaved correctly - CTRL-C affected only the remote command
  • Just reinstalled 2.34.1.windows.1 and tested this. While the Python script doesn't produce a KeyboardInterrupt, if I run SSH directly, I still get exit code 130.
• 2.36.0.rc0.windows.1 had a similar but worse bug where CTRL-C during an SSH session would immediately kill the SSH command ( ctrl+c in gitbash on windows terminal kills ssh remote sessions microsoft/terminal#12431 )

[dscho]

I suspect that you'll most likely get the same behavior in Cygwin when using a build right off of the cygwin-3_3-branch. It's too sad that https://github.com/cygwin/cygwin/actions/runs/2293880675/workflow does not contain a step to upload the artifacts, otherwise you could test much more conveniently.

[dscho]

FWIW it should be as easy as adding something like this at the end of the workflow:

- uses: actions/upload-artifact@v2
  with:
    name: install
    path: install

[macdjord]

@dscho I have nothing to do with Cygwin and have no control over their workflow.

Also, I have discovered something that's probably related: if I use CTRL-C inside vagrant ssh, it immediately exits the session.

[dscho]

Since Git for Windows relies on the MSYS2 Runtime for its Bash, and the MSYS2 Runtime is a close derivative of the Cygwin runtime, you have quite a bit to do with Cygwin, @macdjord, in fact, I strongly suspect the root issue to lie within the Cygwin runtime's source code. And if that is true, the bug fix will need to be implemented in Cygwin, too, and it is quite probable that some Cygwin folks would be helpful in this regard if we could demonstrate that Cygwin itself (without the MSYS2 patches on top) already displays the bug. Hence my suggestion to build something based on the cygwin-3_3-branch.

[Pyker]

I'm fairly certain the point @macdjord was making is that they're not a Cygwin maintainer.

[macdjord]

@dscho: @Pyker has it. I'm not a Cygwin maintainer or contributor, and have no idea how to build anything based on a specific Cygwin branch.

[macdjord]

Issue persists in git version 2.37.1.windows.1. Guess its back to 2.34.1 for me again.

[DWesl]

I suspect that you'll most likely get the same behavior in Cygwin

On Cygwin:

[local] $ ssh server
...
[server] $ ^C
[server] $ ^D
[local] $ echo $?
130
[local] $ ssh server
...
[server] $ ^D
[local] $ echo $?
0

so this seems to reproduce in Cygwin (using the Cygwin ssh updated today, nothing built from source).

It's too sad that [Cygwin's CI] workflow does not contain a step to upload the artifacts, otherwise you could test much more conveniently

You can usually ask on the mailing list for a new snapshot; you may need to change the directions for MSYS2/Git for Windows Bash.

FWIW it should be as easy as adding something like this at the end of the workflow

dscho I have nothing to do with Cygwin and have no control over their workflow.

The workflow change suggestion seems to be directed more at some hypothetical enterprising person who wants to make downstream maintainers' lives easier than at any particular person on this thread, but that seems to have been unclear enough to confuse people.

I strongly suspect the root issue to lie within the Cygwin runtime's source code. And if that is true, the bug fix will need to be implemented in Cygwin, too, and it is quite probable that some Cygwin folks would be helpful in this regard if we could demonstrate that Cygwin itself (without the MSYS2 patches on top) already displays the bug.

not sure what you want to do next

[dscho]

It's too sad that [Cygwin's CI] workflow does not contain a step to upload the artifacts, otherwise you could test much more conveniently

You can usually ask on the mailing list for a new snapshot; you may need to change the directions for MSYS2/Git for Windows Bash.

Right, or you simply fork https://github.com/cygwin/cygwin/, create a branch, edit .github/workflows/cygwin.yml to append a step at the end to upload the build output, i.e. something like this:

- uses: actions/upload-artifacts@v3
  with:
    name: build
    path: build

then push, wait for the workflow to run and finish, then download the build.zip artifact from that run, then test.

FWIW it should be as easy as adding something like this at the end of the workflow

dscho I have nothing to do with Cygwin and have no control over their workflow.

The workflow change suggestion seems to be directed more at some hypothetical enterprising person who wants to make downstream maintainers' lives easier than at any particular person on this thread, but that seems to have been unclear enough to confuse people.

I am sorry that I wasn't clearer. Maybe you can help with communicating in the Git for Windows project? I would really, honestly love that.

I strongly suspect the root issue to lie within the Cygwin runtime's source code. And if that is true, the bug fix will need to be implemented in Cygwin, too, and it is quite probable that some Cygwin folks would be helpful in this regard if we could demonstrate that Cygwin itself (without the MSYS2 patches on top) already displays the bug.

not sure what you want to do next

The best way to go forward, now that it is confirmed to be a bug in Cygwin that reproduces there, would probably be to send that bug report to the Cygwin project. They seem to suggest to send a mail with a detailed bug report to the Cygwin mailing list.

[DWesl]

Following suggestions in msys2/msys2-runtime#83, I tried with CYGWIN=disable_pcon and CYGWIN=enable_pcon, both had the same problem. I tried rolling back Cygwin to 3.3.4-2, then 3.3.3-1 (from 3.3.5-1), and openssh to 8.9p1 from 9.0p1. All had the same problem. I then tried

[local] $ ssh server
...
[server] $ ^C
[server] $ true
[server] $ ^D
[local] $ echo $?
0

so I suspect the Cygwin behavior, at least, is intentional on the part of Cygwin and/or SSH. Does the same thing happen in Git for Windows bash if a command completes successfully after the keyboard interrupt (both with and without the wrapper script)?

I'm kind of curious why the Python wrapper terminates with a KeyboardInterrupt, since ssh already handled that signal; perhaps it forgot to clear it after processing?