Vscode-remote-release: delay-shutdown error when using proxy

[magic-k]

• VSCode Version: 1.36
• Local OS Version: Win 10
• Remote OS Version: Ubuntu 19.10
• Remote Extension/Connection Type: SSH

Steps to Reproduce:

1. Open folder on remote VM
2. Open second folder in another window on the same VM

Does this issue occur when you try this locally?: No
Does this issue occur when you try this locally and all extensions are disabled?: Yes

I have several project all running on a single Ubuntu VM. Sometimes i have up to 3 VSCode Windows with different folders/workspaces running. Worked perfectly with 1.35.1. Bun since the update to 1.36 i can't connect more than once. And even if i close the first window, the second can't connect as long as the previous vscode server is running. Here is the output from the second window:

Found existing installation at /home/omp/.vscode-server/bin/0f3794b38477eea13fb4
7fbe15a42798e6129338...

Found running server...

*

• Reminder: You may only use this software with Visual Studio family products,
• as described in the license (https://go.microsoft.com/fwlink/?linkid=2077057)
  *

Checking server status with wget

http://127.0.0.1:44649/delay-shutdown: 2019-07-04 10:40:07 FEHLER 503: Service U
navailable.
63f356be-431d-4b4c-aa33-118d4289707e##28##

"install" terminal command done
Received install output: 63f356be-431d-4b4c-aa33-118d4289707e##28##
Server status check failed - waiting and retrying 4

[wangtao0101]

same error for commit 0f3794b38477eea13fb47fbe15a42798e6129338

[magic-k]

Even worse:
Connect via remote ssh
Install Extension on Host
Restart as by clicking "restart needed"
VSCode cant reconnect, same error as above even with only one connection.

Edit:
vscode reconnected after 10 retries, i assume that was the shutdown server after 10 minute idle feature.

[rolandoldengarm]

Yep got the same issue, it was working before the latest updates

If you run into the "retrying" issue, that means a previous process is still active. Log in via SSH and run:
pgrep -f "vscode" | xargs kill

[magic-k]

That works but i want/need multiple servers running for different vscode
windows.

Am Do., 4. Juli 2019 um 22:59 Uhr schrieb Roland Oldengarm <
[email protected]>:

Yep got the same issue, it was working before the latest updates

If you run into the "retrying" issue, that means a previous process is
still active. Log in via SSH and run:
pgrep -f "vscode" | xargs kill

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-remote-release/issues/895?email_source=notifications&email_token=ADCPMASC6SEQMNHBCW52B5TP5ZQBNA5CNFSM4H5V35RKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZIEA7A#issuecomment-508575868,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADCPMASKOMNY4DBEK7SJHLDP5ZQBNANCNFSM4H5V35RA
.

[kmalloc]

here problem here, this is troublesome, I have to kill every vscode process each time I want to use remote-ssh.

[DavidA2014]

I agree with @kmalloc, I have to kill the vscode processes every time I start a new remote connection. Also, the output of the kill command is unclear:

$ sudo pgrep -f "vscode" | xargs kill
kill: sending signal to 9037 failed: Operation not permitted
kill: sending signal to 9045 failed: Operation not permitted
kill: sending signal to 14369 failed: No such process
kill: sending signal to 14459 failed: No such process

[roblourens]

Very strange, I don't know why the server is returning 503. Others, please also post your logs so I can check that it is the same error. If not the same, you can open a new issue.

When you are successfully connected, can you try these on your remote: wget 127.0.0.1:<port>/delay-shutdown and also just wget 127.0.0.1:<port> (should be 404).

Also when you see this error, please share cat ~/.vscode-server/.<hash>.log to see if the server was stuck in the middle of shutting down or something like that.

[roblourens]

Also I have pushed a change that should work around this for now, please try with the latest nightly ssh extension

[wangtao0101]

@roblourens maybe it is casused by wget. After i add 'no_proxy=127.0.0.1' in .wgetrc, this issue gone. Is it a new feature that use 'http://127.0.0.1:44649/delay-shutdown:' to check the vscode remote service status?

[roblourens]

Oh, maybe the 503 is from the proxy, not our server. Is everyone using a proxy for this?

[jemerald]

Yes, we are using a proxy server. and adding no_proxy=127.0.0.1 fixes it.

[kmalloc]

@roblourens maybe it is casused by wget. After i add 'no_proxy=127.0.0.1' in .wgetrc, this issue gone. Is it a new feature that use 'http://127.0.0.1:44649/delay-shutdown:' to check the vscode remote service status?

no_proxy works for me too, thanks.

[magic-k]

As the issuer i can confirm that no_proxy in .wgetrc fixes the problem. Still, vscode should respect the system enviroment variables, cause there no_proxy is set.

[roblourens]

If no_proxy is set but not being respected, how is it set? Sometimes a .bashrc will bail out if it's not in an interactive session, and our script is not running in an interactive session.

[roblourens]

Pushed a better fix for this, please try it in the next ssh nightly (10 hours from now or so)

[svenkata9]

@roblourens maybe it is casused by wget. After i add 'no_proxy=127.0.0.1' in .wgetrc, this issue gone. Is it a new feature that use 'http://127.0.0.1:44649/delay-shutdown:' to check the vscode remote service status?

no_proxy works for me too, thanks.

This works for me too. Thanks.

[james-potts]

If no_proxy is set but not being respected, how is it set? Sometimes a .bashrc will bail out if it's not in an interactive session, and our script is not running in an interactive session.

While it's technically true that having _http_proxy_ set means that you should also have _no_proxy_ set, I can think of no non-contrived scenario where one would want 127.0.0.1 to go through a proxy server. Especially in this instance. So why not give wget the --no-proxy argument when doing the check?

(I've had http[s]_proxy set for over a decade on my machines at work, and I've never had to add the loopback address to no_proxy until I installed the last vs-code update.)

[roblourens]

So why not give wget the --no-proxy argument when doing the check?

Yeah that's exactly what I've ended up doing. I will push a new stable release with this fix later today. You could try this in the latest nightly ssh build to help me validate that it does work

[roblourens]

v0.44.1 has the fix

[l4zyf9x]

Hey guys, i got sane problem. Here is my stutiation:
First i found that my remote machine can not have connectivity to outside connections. After following #15 i got below problem.

Running remote connection script
Found existing installation at /root/.vscode-server/bin/2213894ea0415ee8c85c5eea0d0ff81ecc191529...
Found running server...

*

• Reminder: You may only use this software with Visual Studio family products,
• as described in the license (https://go.microsoft.com/fwlink/?linkid=2077057)
  *

Checking server status with wget
http://127.0.0.1:41591/delay-shutdown: 2019-07-12 17:47:18 ERROR 404: Not Found.
d05fa4fa-508d-4e37-b2fd-95f8ce49dd7b##28##
"install" terminal command done
Received install output: d05fa4fa-508d-4e37-b2fd-95f8ce49dd7b##28##
Server status check failed - waiting and retrying 30

I try solution given by @jemerald but it still doesn't work.

Yes, we are using a proxy server. and adding no_proxy=127.0.0.1 fixes it.

Does anyone got problem like me?

[roblourens]

@l4zyf9x I don't officially support the workaround in #15 and I'm not sure what issues might come up when the server is offline. It looks possible that you don't have the right version of the server.