petewarden · February 29, 2024 19:18
diff --git a/restart_vscode_on_myth.sh b/restart_vscode_on_myth.sh
 # I use VS Code for Pintos development on Stanford's myth servers, but sometimes it fails to connect
 # and can be hard to reset. Normally I'd delete `~/.vscode-server` on the remote machine, but the
 # networked file system used at Stanford often seems to leave files open semi-permanently even after
 # an SSH session has completed, so if I run `rm -rf ~/.vscode-server` I see errors like:

 $ rm -rf .vscode-server
 rm: cannot remove '.vscode-server/cli/servers/Stable-903b1e9d8990623e3d7da1df3d33db3e42d80eda/server/bin': Directory not empty
 rm: cannot remove '.vscode-server/extensions/ms-vscode.cpptools-1.18.5-linux-x64.-5974b6c6.vsctmp/bin/.__afsC4E7': Device or resource busy

 # To solve this, I've taken to using the `lsof` command to figure out which processes have those
 # files open and killing them. So far I've been doing this manually, since my connection issues only
 # seem to occur every week or two, but it should be possible to automate. Here's what I run:

 $ lsof | grep vscode

 # This gives me a long list of open files related to the VS Code server, along with information about
 # the process that retains the file.

 node      2437315 2437430 node             peteward   23w      REG               0,54   522857  926690508 /afs/.ir.stanford.edu/users/p/e/peteward/.vscode-server/data/logs/20240228T104841/.__afsB89F
 node      2437315 2437430 node             peteward   27w      REG               0,54        0  926694072 /afs/.ir.stanford.edu/users/p/e/peteward/.vscode-server/data/logs/20240228T104841/.__afs07FB

 # The second column is a process ID, so I feed that into the kill command to force it to exit and
 # release the file lock:

 $ kill -9 2437315

 # I repeat this with all the process IDs listed in the `lsof` output, until they're all closed and
 # I can run the `rm -rf ~/.vscode-server` command successfully. At that point I'm usually able to
 # remotely connect to the server using VS Code again.
 # This method will blow away any remotely-installed plugins, and requires a minute or two to 
 # re-download the VS Code server binaries, but it has helped me continue working using the editor
 # at least.
	# I use VS Code for Pintos development on Stanford's myth servers, but sometimes it fails to connect
	# and can be hard to reset. Normally I'd delete `~/.vscode-server` on the remote machine, but the
	# networked file system used at Stanford often seems to leave files open semi-permanently even after
	# an SSH session has completed, so if I run `rm -rf ~/.vscode-server` I see errors like:

	$ rm -rf .vscode-server
	rm: cannot remove '.vscode-server/cli/servers/Stable-903b1e9d8990623e3d7da1df3d33db3e42d80eda/server/bin': Directory not empty
	rm: cannot remove '.vscode-server/extensions/ms-vscode.cpptools-1.18.5-linux-x64.-5974b6c6.vsctmp/bin/.__afsC4E7': Device or resource busy

	# To solve this, I've taken to using the `lsof` command to figure out which processes have those
	# files open and killing them. So far I've been doing this manually, since my connection issues only
	# seem to occur every week or two, but it should be possible to automate. Here's what I run:

	$ lsof \| grep vscode

	# This gives me a long list of open files related to the VS Code server, along with information about
	# the process that retains the file.

	node 2437315 2437430 node peteward 23w REG 0,54 522857 926690508 /afs/.ir.stanford.edu/users/p/e/peteward/.vscode-server/data/logs/20240228T104841/.__afsB89F
	node 2437315 2437430 node peteward 27w REG 0,54 0 926694072 /afs/.ir.stanford.edu/users/p/e/peteward/.vscode-server/data/logs/20240228T104841/.__afs07FB

	# The second column is a process ID, so I feed that into the kill command to force it to exit and
	# release the file lock:

	$ kill -9 2437315

	# I repeat this with all the process IDs listed in the `lsof` output, until they're all closed and
	# I can run the `rm -rf ~/.vscode-server` command successfully. At that point I'm usually able to
	# remotely connect to the server using VS Code again.
	# This method will blow away any remotely-installed plugins, and requires a minute or two to
	# re-download the VS Code server binaries, but it has helped me continue working using the editor
	# at least.