Repository navigation
Fail to create tls-proxy for the second process. #2200
Description
- Web Browser: Chrome
- Local OS: Windows 10
- Remote OS: Ubuntu 16.04
- Remote Architecture: x86_64
code-server --version: 3.5.0
When running two process in the same server by two different users, the second one won't work and gives the following error:
discarding socket connection: EACCES: permission denied, unlink '/tmp/code-server/tls-proxy'
Notice that the tls-proxy is created by the first process. Obviously, it is not accessible by the second process.
After a little research, I find out that this bug is caused by a logic error in socket.ts, line 94.
public async findFreeSocketPath(basePath: string, maxTries = 100): Promise<string> {
let i = 0
let path = basePath
while ((await canConnect(path)) && i < maxTries) { // the line with bug
path = `${basePath}-${++i}`
}
return path
}which should be
public async findFreeSocketPath(basePath: string, maxTries = 100): Promise<string> {
let i = 0
let path = basePath
while (!(await canConnect(path)) && i < maxTries) { // fix the bug
path = `${basePath}-${++i}`
}
return path
}When the current path is not accessible, then try next one.
What is interesting is that when the second user is
root, thencanConnectreturnstruein the original code, a new socket filetls-proxy-1is created successfully. So that I think the code here should be further modified. We should check if there is a file inpath. If there is a file here, we should not use this even it is accessible unless the current user is not root.
There is another problem here: the directory /tmp/code-server is created and owned by the first user, which means this directory is not writable for the second user, so the new socket file tls-proxy-1 cannot be created. I have to manually change the permissions of the directory to make everything works.
Ok I forget one last thing. When I fix every as discribed above, the web client still shows nothing. After checking chrome console, a 404 error occurs for file in path code-server/release-standalone/dist/pages/pages/vscode.js. Notice that there are two pages here, while the structure of the dist folder is dist/pages/vscode.js. I have to manually create another pages folder, and copy everything else into it.
finally, everything works fine.
Activity
code-asher commentedon Oct 15, 2020
huangy10 commentedon Oct 15, 2020
I try to replicate this time and it is gone now. But I find a very very interesting thing!
I wrap my url to the code-server with nativefier to create a standalone native application in Win10. Within the built-in console in the wrapped app, I run a new code-server process on my remote server on a different port. Normally it should print some logs, and I should open a new chrome page and visit the new port. However, this time a new window of the native app is automatically created, which lead me to the code-server service on the new port!
huangy10 commentedon Oct 15, 2020
Now everything is crazy. As I said in the last comment, running code-server within the console of the native application wrapped by nativefier, a new window is displayed as ask for password. Since the new code-server command is simply
./code-server --bind-addr 0.0.0.0:5010 ., it means the same default configuration file~/.config/code-server/.config.yamlis used. Thus I input the password defined in that file, and the authentication succeeds.Next, I want to replicate this, so I close the new window, and run the code-server in the native app again. This time a new window is created but nothing is displayed. What is worst is that the original code-server process is corrupted!
I check the log of the first code-server process, and it says:
To conclude everything above: If two code-servers are started by the same user, then the second process may still try to use the tls-proxy created by the first process (note that here I fix the bug mentioned above and use the code-server binary built by myself), which may corrupt everything. Notice that the tls-proxy file is indeed accessible by the second process, but the connection number is limitted.
When I say 'the original code-server process is corrupted', I mean that even if I stop all other code-server process, and the tls-proxy does not exist (It is not manually deleted, I think it is deleted by other code-server process on exit). The original code-server process still holds some kind of handler to that deleted tls-proxy file. So when new connection comes, instead of creating a new tls-proxy, it tries to connect the deleted socket file, which will certainly fail.