Visual Studio Code for Remote Development
- Alexis Espinosa
- Kevin Buckley
- Sarah Beecroft
Visual Studio Code is a popular free and open-source code editing application that can be deployed on Linux, macOS and Windows. It has an integrated terminal within its user interface that removes the need to switch between command-line tasks and code editing. The functionality of VS Code can easily be extended by installing extensions. These extensions allow for almost arbitrary language support, debugging or remote development.
Visual Studio Code can cause severe problems in login nodes and user's own quota
VS code is a very popular tool, but it has caused severe problems on Setonix shared resources. So, users should be aware of its potential problems, which generally affect not only the intial user, but the rest of users accessing our shared resources. And, therefore, use the tool with care and strictly following the recommendations/settings indicated in Pawsey Documentation for dealing with possible nasty issues created by this tool.
Current list of know issues are:
- VS code can create enough files to fill up your $HOME quota. To avoid this, try to stick to only installing extensions that are needed, as many extensions can take up more space than you'd like. You can occasionally remove the `~/.vscode-server` directory, which can accumulate excess files.
- VS code can leave orphan processes running (and occupying resources indefinitely) in the login nodes. To avoid this, users should explicitly close the remote connections once they have finished their working session. Users should also regularly check for orphan processes in the login nodes.
- VS code can overload resources in the login nodes when automatic filewatcher and search is active. To avoid this, users should restrict the extent of action of these tools together with the TypeScript and JavaScript language services.
Detailed recommendations are given in the rest of this page, so VS code users should read the whole page and follow the settings/recommendations within.
Installation and intial settings
Please refer to the Visual Studio HomePage (external site) to learn more about Visual Studio Code and for downloading and installation instructions. The default terminal shell is bash on Linux and macOS, and PowerShell on Windows. (Windows users must install Git for Windows (external site) to then configure the default terminal shell to bash.)
Although the integrated terminal on Visual Studio Code can be used directly to SSH login to Pawsey systems, the Remote Development extension pack provides the ability to open remote directories and text files on Visual Studio Code for in-app code editing and building. The Remote Development extension pack is easily installed from the Marketplace within the application. There are instructions for downloading the Remove Development extension here. See also the instructions on the official web page Remote Development using SSH (external site).
After the standard installation procedure, you may also need to check the box for Remote.SSH: Lockfiles in Tmp, under Settings, in order to connect to Pawsey systems.
Best practices and recommendations
Preventing the leftover of orphan processes running in login nodes indefinitely
Always end the remote session with explicit click in the "Close Remote Connection" button
If you want to end your remote session, click the "SSH connection status" box in the lower left corner. Then, in the input box that opens, select the "Close Remote Connection" option.
Figure 2. Example of Visual Studio Code screen feature that allows clean disconnection from SSH session.
Always close the remote session
Always follow the exit process described above. If you don't and simply close your VS Code window, then some server-side components of VS Code will continue to run remotely.
Kill the leftover orphan processes in the login nodes
VS Code users should perform this cleaning regularly
VS Code may leave orphan processes consuming resources in the login nodes even when users have ended their VS Sessions or turned-off their computer. All VS Code users should perform the check/clean tasks indicated here with regularity.
VS Code is a handy tool, but comes with some side-effects that may affect you and other users of Setonix. One of these problematic side-effects is the unexpected left over of orphan processes consuming resources in the login nodes even when users have ended their VS Sessions or turned-off their computer. If Visual Studio Code has left some related processes running on the login nodes, these may use CPU and complicate you and other users to log into Setonix. The current solution for this is a bit painful and requires the use of manual investigation/cleaning by users.
To identify Visual Studio Code leftovers, exit completely from any session of VS code running on your computer. Then, users should connect to Setonix by other means (like the use of a terminal recommended in Connecting to a Supercomputer using SSH). If the user knows exactly the login node where the orphan processes reside, they can connect directly to that login node. So, if orphan processes are in "setonix-03", then users can connect directly to that login node with:
ssh <userName>@setonix-03.pawsey.org.au
If users are performing a regular check for orphan processes, then they will need to access the login and data-mover nodes individually and check for orphan processes on each of them.
At any given time, the set of login and data-mover nodes that are accessible may be determined by running the following commands from a terminal session on whichever login or data-mover node you have logged into
username@setonix-06:~> dig @150.229.2.5 setonix.pawsey.org.au +noall +answer setonix.pawsey.org.au. 3600 IN A 146.118.12.26 setonix.pawsey.org.au. 3600 IN A 146.118.12.27 setonix.pawsey.org.au. 3600 IN A 146.118.12.22 username@setonix-06:~> username@setonix-06:~> nslookup 146.118.12.26 150.229.2.5 26.12.118.146.in-addr.arpa name = setonix-05.pawsey.org.au. username@setonix-06:~> username@setonix-06:~> nslookup 146.118.12.27 150.229.2.5 27.12.118.146.in-addr.arpa name = setonix-06.pawsey.org.au. username@setonix-06:~> username@setonix-06:~> nslookup 146.118.12.22 150.229.2.5 22.12.118.146.in-addr.arpa name = setonix-01.pawsey.org.au. username@setonix-06:~>
Here, having logged into setonix-06, we obtain the list of IP addresses for the currently accessible login nodes, and then convert those IP addresses back into the individual nodes names.
in this instance, we can see that we should also check for leftover processe on setonix-01 and setonix-05
The following example shows the commands to obtain the list of names for the currently available data-mover nodes, having logged into setonix-dm01
username@setonix-dm01:~> dig @150.229.2.5 data-mover.pawsey.org.au +noall +answer data-mover.pawsey.org.au. 3600 IN A 146.118.74.161 data-mover.pawsey.org.au. 3600 IN A 146.118.74.160 data-mover.pawsey.org.au. 3600 IN A 146.118.74.163 data-mover.pawsey.org.au. 3600 IN A 146.118.74.162 username@setonix-dm01:~> username@setonix-dm01:~> nslookup 146.118.74.161 150.229.2.5 161.74.118.146.in-addr.arpa name = setonix-dm02.pawsey.org.au. username@setonix-dm01:~> username@setonix-dm01:~> nslookup 146.118.74.160 150.229.2.5 160.74.118.146.in-addr.arpa name = setonix-dm01.pawsey.org.au. username@setonix-dm01:~> username@setonix-dm01:~> nslookup 146.118.74.163 150.229.2.5 163.74.118.146.in-addr.arpa name = setonix-dm04.pawsey.org.au. username@setonix-dm01:~> username@setonix-dm01:~> nslookup 146.118.74.162 150.229.2.5 162.74.118.146.in-addr.arpa name = setonix-dm03.pawsey.org.au. username@setonix-dm01:~>
Only connect to specific login nodes to perform killing of orphan processes
Only use direct connection to specific login nodes when performing cleaning of orphan processes. For the rest of your connections users should be using the generic name setonix.pawsey.org.au, which provides access assigning the connection to different login nodes in a round robin fashion. This allows for better load balancing of resources among all users. Furthermore, the use of the generic name provides a more reliable access as it can provide service to users on active login nodes while some specific login nodes may have been taken down by Pawsey staff for technical reasons.
Once the user has logged into the desired login node, execute the ps command together with "filtering" with the grep command acting repeatedly on the output to narrow it down to only those processes owned by the user and related to "vscode":
$ ps -fea | head -n 1 ; ps -fea | grep ${USER} | grep -i "vscode" | grep -v "grep"
UID PID PPID C STIME TTY TIME CMD
matilda 236771 1 0 11:55 ? 00:00:00 sh /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/bin/code-server --start-server --host=127.0.0.1 --accept-server-license-terms --enable-remote-auto-shutdown --port=0 --telemetry-level all --connection-token-file /home/matilda/.vscode-server/.fdb98833154679dbaa7af67a5a29fe19e55c2b73.token
matilda 236784 236771 0 11:55 ? 00:00:02 /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/node /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/out/server-main.js --start-server --host=127.0.0.1 --accept-server-license-terms --enable-remote-auto-shutdown --port=0 --telemetry-level all --connection-token-file /home/matilda/.vscode-server/.fdb98833154679dbaa7af67a5a29fe19e55c2b73.token
matilda 237900 236784 99 11:55 ? 02:37:53 /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/node --dns-result-order=ipv4first /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/out/bootstrap-fork --type=extensionHost --transformURIs --useHostProxy=false
matilda 237945 236784 0 11:55 ? 00:00:00 /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/node /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/out/bootstrap-fork --type=ptyHost --logsPath /home/matilda/.vscode-server/data/logs/20231003T115510
(Note that the first part of the command above (before the semicolon ";") is to keep displaying the header of the ps command.)
As the user has already disconnected from any VS Code active session, and the "cleaning" connection is being performed outside VS Code, then users can visually confirm that those processes are indeed the orphan processes of interest. Now they can proceed to kill them by extending the command to extract a list of the process IDs and passing that list to the kill command:
$ ps -fea | grep ${USER} | grep -i "vscode" | grep -v "grep" | awk '{print $2}' | xargs kill -9
#Confirm that after killing, no vscode process exist:
$ ps -fea | head -n 1 ; ps -fea | grep ${USER} | grep -i "vscode" | grep -v "grep"
UID PID PPID C STIME TTY TIME CMD
$
Now that users are taking some time to clean the login nodes from their orphan processes then, as recommended above, it is a good idea to go through all the active login nodes and perform a check on all of them (and kill the orphan processes that are identified).
If you find that after killing orphan processes in all the login nodes is still giving you problems to login using VS code. Then, you may need to purge the Visual Studio Code directory on Setonix using the following:
$ rm -rf ~/.vscode-server/
Preventing Visual Studio Code overloading the login nodes
Avoid filewatcher and file searcher to pay attention to directories with large number of files
The Visual Studio Code filewatcher and file searcher (rg) indexes all the files you have access to in your workspace. If you have a large dataset (e.g. machine learning) this can take a lot of resources on the login nodes. Please note that making some changes to your settings.json file on Setonix can prevent this issue.
# Create the settings.json file
$ touch ~/.vscode-server/data/Machine/settings.json
# add the following information to settings.json with your favourite text editor
"files.watcherExclude": {
"**/.git/objects/**": true,
"**/.git/subtree-cache/**": true,
"**/node_modules/*/**": true,
"/usr/local/**": true,
"/scratch/**": true},
"search.followSymlinks": false,
"search.exclude": {
"**/.git/objects/**": true,
"**/.git/subtree-cache/**": true,
"**/node_modules/*/**": true,
"/usr/local/**": true,
"/scratch/**": true},
Note that we are explicitly telling VS Code not to watch or search in directories named as indicated nor in the whole /scratch file system. And, if you know of some other directory in your files that contain a large number of files and on which you really don't need VS Code to pay attention to its contents and changes, then it is highly recommended to add its name within the settings as "**/knownDirectoryWithLotsOfFiles/**".
Disable TypeScript and JavaScript Language Services
It's also important to disable the TypeScript and JavaScript Language Services.
- Hit the extensions button in VS Code (which looks like building blocks on the left toolbar)
- Search for ‘@builtin TypeScript’.
- Disable the TypeScript and Javascript Language Features extension
- Reload
Preventing Visual Studio Code to consume your quota in the $HOME file system
Home is often used by a variety of programs use store configuration files and directories along with some cached information. These directories can contain many files and use up quite a bit of storage. An example is Note that we are using vscode, which stores quite a bit of data within the .vscode-server directory located in $HOME . This directory can contain upwards of 1000 files and use on the order of 100 MB. This will impact your quota on home. We recommend moving such directories to a "fakeHome" directory in: /software/projects/<project>/<username>/fakeHome. Then generate a symbolic link in $HOME that points to the corresponding directory:$ mkdir -p $MYSOFTWARE/fakeHome
$ cp -r $HOME/.vscode-server $MYSOFTWARE/fakeHome # if .vscode_server dir initially exists in $HOME
$ rm -r $HOME/.vscode-server # if .vscode_server dir initially exists in $HOME
$ mkdir -p $MYSOFTWARE/fakeHome/.vscode-server # if .vscode_server did not initially existed in $HOME
$ ln -s $MYSOFTWARE/fakeHome/.vscode-server $HOME/.vscode-server # generate a symbolic link
cp + rm and not mv to transfer the .vscode-server directory to another filesystem in order to get the right ownership of files in the new filesystem and remove their original ownership that is consuming the $HOME quota, otherwise the quota of the transferred files would still be assigned to $HOME quota.