vscode remote-SSH bash: cannot set terminal process group (PGID): Inappropriate ioctl for device

[therealkenc]

• Your Windows build number: 18890
• What you're doing and what's happening:

VS Code blog to install version 1.34.0-insider on Native Ubuntu 18.04 with Remote - SSH plugin 0.34.0 here and more helpful docs here. Ref Microsoft/vscode#63155. On WSL side, OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 on Ubuntu 18.04.

Running the Remote - SSH plugin with WSL works admirably on a quick looksee; however on establishing the remote login session, the following (soft?) error occurs. You can find the output on the local native Ubuntu instance of VS Code in View -> Output -> Remote - SSH, which dumps the output from the remote WSL side.

[ n.b. This is not the "Remote - WSL" plugin, this is native Ububtu to WSL with the "Remote - SSH" plugin. The new ecosystem is nonobv for the uninitiated, where uninitiated means most everyone prior to around 8 hours ago. No CLI repro yet (working on it). Hesitate to post in the VS Code github since the problem fairly clearly isn't in their wheelhouse.]

SSH Resolver called for "ssh-remote+7b22686f73744e616d65223a223139322e3136382e302e313835222c2275736572223a226b656e227d"
SSH Resolver called for host: ken@192.168.0.185
Setting up SSH remote "192.168.0.185"
Using commit id "473af338e1bd9ad4d9853933da1cd9d5d9e07dc9" and quality "insider" for server
Install and start server if needed
> Welcome to Ubuntu 18.04.2 LTS (GNU/Linux 4.4.0-18890-Microsoft x86_64)
[...blah blah]
> 0 packages can be updated.
> 0 updates are security updates.
> 
> 
> bash: cannot set terminal process group (6147): Inappropriate ioctl for device
> bash: no job control in this shell
> Found existing installation...
> Found running server...
[...blah blah]
> 6929d891-cea0-46a9-8140-6d2243428cc8==52680==
"install" terminal command done
Received install output: 6929d891-cea0-46a9-8140-6d2243428cc8==52680==
Server is listening on port 52680
Spawning tunnel with: ssh  ken@192.168.0.185 -N -L localhost:58834:localhost:52680
Spawned SSH tunnel between local port 58834 and remote port 52680
Waiting for ssh tunnel to be ready
Tunneling remote port 52680 to local port 58834
Resolving "ssh-remote+7b22686f73744e616d65223a223139322e3136382e302e313835222c2275736572223a226b656e227d" to "localhost:58834", attempt: 1

Relevant part being:

> bash: cannot set terminal process group (6147): Inappropriate ioctl for device
> bash: no job control in this shell

Getting in under the hood to find the ioctl() is not going to be trivial. That PGID 6147 is almost certainly okay. There is no error on a loopback remote session back to native Ubuntu, natch, so the problem is going to be some diverge.

For the purposes of question tag: Any WAG? Really I am hoping for a dupe that might get some grease, but after a fairly extensive survey of open issues I couldn't find anything obviously related that hasn't already been addressed.

[therealkenc]

Aight, the error is from here (one of those two error paths). [retraction ed] I wanted to finger #3650 but after harder thought I can't convince myself that's it. We know this is a ENOTTY on TIOCGPGRP or TIOCSPGRP, but not much can be said otherwise about the process group itself (it's probably fine).

[therealkenc]

Got an strace log here. Can be captured on the WSL side with:

$ sudo strace -f -o sshd.strace /usr/sbin/sshd -D

In my run, the crux of the error starts around line 80259. Eventually sshd spawns /bin/bash (here PID 1085). Without being too premature about drawing conclusions, that openat(AT_FDCWD, "/dev/tty", ...) returning ENOTTY is (let's call it) "unusual".

What causes the actual user facing error message is a little further down on the the ioctl(255, TIOCGPGRP, ...), where fd 255 is a dup of fd 3, and fd 3 is a dup of fd 2 -- which I assume is just stderr inherited from the parent. WSL doesn't think fd 2 is a TTY either.

1085  getppid()                         = 1077
1085  gettimeofday({tv_sec=1556999225, tv_usec=605299}, NULL) = 0
1085  getpid()                          = 1085
1085  getpgrp()                         = 1077
1085  ioctl(2, TCGETS, 0x7fffe926ad40)  = -1 ENOTTY (Inappropriate ioctl for device)
1085  openat(AT_FDCWD, "/dev/tty", O_RDWR|O_NONBLOCK) = -1 ENOTTY (Inappropriate ioctl for device)
1085  dup(2)                            = 3
1085  prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024, rlim_max=4*1024}) = 0
1085  fcntl(255, F_GETFD)               = -1 EBADF (Bad file descriptor)
1085  dup2(3, 255)                      = 255
1085  close(3)                          = 0
1085  ioctl(255, TIOCGPGRP, 0x7fffe926adc4) = -1 ENOTTY (Inappropriate ioctl for device)
1085  getpid()                          = 1085
1085  setpgid(0, 1085)                  = 0
1085  rt_sigprocmask(SIG_BLOCK, [CHLD TSTP TTIN TTOU], [], 8) = 0
1085  ioctl(255, TIOCSPGRP, [1085])     = -1 ENOTTY (Inappropriate ioctl for device)
1085  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
1085  setpgid(0, 1077)                  = 0
1085  openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
[...blah blah unrelated langpack stuff for error message]
1085  write(2, "bash: cannot set terminal proces"..., 79) = 79
1085  write(2, "bash: no job control in this she"..., 35 <unfinished ...>
1085  <... write resumed> )             = 35
[...blah blah]

[ed] Okay that openat() ENOTTY is unusual but not wrong (other than it probably should be ENXIO). This is due to privilege separation, which is now mandatory as of OpenSSH 7.5. Still needs investigation why fd 2 aka fd 255 is not a TTY, or where Real Linux and WSL part ways exactly....

[therealkenc]

Calling this fix-in-wsl2 since I'm pretty okay with never knowing why fd 2 aka fd 255 is not a TTY above, and the problem does not manifest in WSL2.