CTRL+C won't interrupt SSH client attempting to connect to a non answering host

[omartin2010]

Simply trying to ssh to a host that doesn't exist and trying CTRL+C to avoid having to wait until timeout happens... which doesn't work as it does on a regular linux Ubuntu.
omartin@DESKTOP-10OCDI0:~$ ssh [email protected]
^C^C^C^C^C

I'm running build 15063.413 with 16.04 Ubuntu... I tried to look into the opened issues, it doesn't seem to be there.

[omartin2010]

won't interrupt traceroute neither. Maybe something socket related...

[fpqc]

what about

<enter> ~.

in ssh?

[omartin2010]

doesn't work more...

ssh omartin@DESKTOP-10OCDI0:~$ ssh [email protected]
..^C

omartin@DESKTOP-10OCDI0:~$

[sunilmut]

@omartin2010 - Thanks for your post. You were correct with your statement Maybe something socket related. The issue was that the connect socket syscall was not-interruptable. That was fixed sometime back, but after Creators Update (build 15063). I tried it on the latest Insider build 16215 and it seems to be fixed.

[omartin2010]

Ok, thanks! From: Sunil Muthuswamy [mailto:[email protected]] Sent: Thursday, June 15, 2017 13:22 To: Microsoft/BashOnWindows <[email protected]> Cc: Olivier Martin <[email protected]>; Mention <[email protected]> Subject: Re: [Microsoft/BashOnWindows] CTRL+C won't interrupt SSH client attempting to connect to a non answering host (#2220) @omartin2010<https://github.com/omartin2010> - Thanks for your post. You were correct with your statement Maybe something socket related. The issue was that the connect socket syscall was not-interruptable. That was fixed sometime back, but after Creators Update (build 15063). I tried it on the latest Insider build 16215 and it seems to be fixed. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#2220 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AK2FXmCT5IgaEt-Y9QTPsx3-4JnSmdAJks5sEWhCgaJpZM4N6sof>.

[therealkenc]

The issue was that the connect socket syscall was not-interruptable

@sunilmut - Are there other syscalls that are known to have this limitation? I am still having trouble breaking gdb like here, but I don't know if the problem is debugger related (signals, ptrace, etc) or just a more general problem with the debuggee being stuck in an uninterruptible syscall. Bearing in mind that the code in question (chrome) is almost certainly stuck in network related activity (either AF_INET or inter-process AF_NETLINK) -- because that's mostly what the software does for a living at the kernel interface boundary. The inability to break persists in 16215.

[sunilmut]

@therealkenc - We are not aware of any other syscall that has this limitation. Though confirming that would require a full pass over the code. In your scenario:

1. Are these reproducible?
2. Are these hung operations ever timing out? If so, then an strace with a search for some timeout related error might provide some insight.

[therealkenc]

Are these reproducible?

Completely reproducible, but not under a sanctioned WSL use-case, which is why I haven't opened a new github issue. It's a recvmsg() that EAGAINs forever ultimately causing a futex to timeout and a thread to die, and everything goes south from there. You can SIGINT the code when run from the command line but not under gdb. I'd post the 70k line strace but it probably isn't worth your time until #1006, #1910, and the ENOSYS #2053 issues flip. Known issues before unknown issues, I say. But if you are feeling masochistic say the word and I'll open a separate issue with pretty straightforward (if unsupported) steps.

[sunilmut]

If You can SIGINT the code when run from the command line but not under gdb. is true, then it feels to me more of a ptrace issue than a non-interruptable syscall. We definitely have some known issues on the ptrace side of things #2216, #555, #204. But, not sure if they are related.

[therealkenc]

Yeah almost certainly a "gdb thing". My question was mostly grasping out of desperation for an explanation, on the chance you might name some other syscalls that can't be interrupted. Just hoping for an ah-ha. It probably isn't #555/#2216 proper; if gdb was hitting unimplemented ptrace surface, the EINVAL would be glaring. Could be #204; that issue is kind of dangling. But it isn't spinning on a busy loop like Adam's test case, which anyway has probably been addressed. There are plenty of syscalls being made that should notice the SIGINT. After the fact, the process under gdb can only be put to rest with SIGKILL from another term. Anyway, I was just stopping by because of the "^C^C^C^C^C" report. Thanks for the follow-up thoughts.