...
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. If you simply close your VS Code window, some server-side components of VS Code will continue to run remotely.
| Column | ||
|---|---|---|
| ||
Figure 2. Example of Visual Studio Code screen feature that allows clean disconnection from SSH session. |
...
| Column | |||||
|---|---|---|---|---|---|
| |||||
|
Kill the leftover orphan processes in the login nodes
| Column | |||||
|---|---|---|---|---|---|
| |||||
|
...
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). Once If the user has logged into Setonix, execute the ps command together 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":
...
| width | 900px |
|---|
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
$ ps -fea | grep ${USER} | grep -i "vscode" | grep -v "grep"
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 |
Once users can visually confirm that those are indeed only the orphan processes of interest, they can proceed to kill them by extending the command to extract a list of the process IDs and pass it to the kill command:
...
| width | 900px |
|---|
...
| language | bash |
|---|---|
| theme | DJango |
| title | Terminal 3. Killing unexpected/orphan VS Code processes |
...
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
| Code Block | ||
|---|---|---|
| ||
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
| Code Block | ||
|---|---|---|
| ||
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:~> |
| Column | |||||
|---|---|---|---|---|---|
| |||||
|
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":
| Column | |||||||||
|---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
(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:
| Column | |||||||||
|---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
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:
...
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.
...
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 withing within the settings as "**/knownDirectoryWithLotsOfFiles/**".
...
Disable TypeScript and JavaScript Language Services
It's also important to disable the TypeScript and JavaScript Language Services.
...
Preventing Visual Studio Code to consume your quota in the $HOME file system
| Excerpt |
|---|
Home is often used by a variety of programs |
...
to store configuration |
...
| Column | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Code Block | | ||||||||||
|
| Column | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
Note that we are using 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.
Further explanation of quotas can be found in Pawsey Filesystems and their Use.
Related pages
...
| Page Tree | ||||
|---|---|---|---|---|
|
Pawsey Filesystems and their Use