UMIACS - Recent changes [en]

MonthlyMaintenanceWindow

Mbaney — Thu, 01 Oct 2026 18:40:16 GMT

← Older revision		Revision as of 18:40, 1 October 2026
(One intermediate revision by the same user not shown)
Line 8:		Line 8:


	* October 22nd 2026		* '''October 9th-13th (datacenter, including Nexus, due to cooling outage)''' and '''October 22nd 2026 (non-datacenter)'''
	* November 19th 2026		* November 19th 2026
	* December 17th 2026		* December 17th 2026

MailmanListAdmin

Mbaney — Fri, 25 Sep 2026 16:31:59 GMT

← Older revision		Revision as of 16:31, 25 September 2026
Line 14:		Line 14:
	LISTNAME-subscribe and LISTNAME-unsubscribe		LISTNAME-subscribe and LISTNAME-unsubscribe

	respectively. In ALL of the above cases, the user will receive email confirming their action. They need to ~~just~~ reply to the ~~mail~~ for this to take effect.		respectively. In ALL of the above cases, the user will receive email confirming their action. They just need to reply to the email for this to take effect.

	===Managing a List===		===Managing a List===
Line 23:		Line 23:
	You will be prompted for the aforementioned password. In general, most of the default settings are likely to be fine but you should know about the following capabilities and pieces of information.		You will be prompted for the aforementioned password. In general, most of the default settings are likely to be fine but you should know about the following capabilities and pieces of information.

	* Just because you are the list administrator doesn't mean you're subscribed to (or ~~you~~ have to be subscribed to) ~~this~~ list.		* Just because you are the list administrator doesn't mean you're subscribed to (or have to be subscribed to) the list.
	* Messages sent out aren't necessarily delivered immediately; it could take up to 5 minutes.		* Messages sent out aren't necessarily delivered immediately; it could take up to 5 minutes.

VS Code

Mbaney — Fri, 25 Sep 2026 16:12:21 GMT

Running VS Code on a Compute Node

← Older revision		Revision as of 16:12, 25 September 2026
Line 50:		Line 50:

	===Running VS Code on a Compute Node===		===Running VS Code on a Compute Node===
	VS Code with resource-intensive LSPs or AI/LLM extensions can cause usability issues on submission nodes. If you are using these extensions, we recommend setting up CPU-only compute jobs to run your IDE in rather than running it on submission nodes.		VS Code with resource-intensive LSPs or AI/LLM extensions can cause usability issues on submission nodes. If you are using these extensions, we recommend setting up CPU-only compute jobs to run your IDE in rather than running your IDE on submission nodes.

	# SSH to your submission node.		# SSH to your submission node.

Nexus/Submission Node Policy

Mbaney — Fri, 25 Sep 2026 15:53:06 GMT

VS Code

Mbaney — Fri, 25 Sep 2026 14:36:03 GMT

Running VS Code on a Compute Node

@@ Line 7: / Line 7: @@
 For a list of active issues with the Remote - SSH extension, please see Microsoft's GitHub tracker [https://github.com/Microsoft/vscode-remote-release/labels/ssh here].
 ===Best Practices===
@@ Line 60: / Line 48: @@
 #: [[File:VSCode-killremote3.png|alt=Pop-up confirming the kill command went through.]]
 #: The next time you connect to the same submission node, you will have a fresh VS Code session on it.
 ==Common Issues==

VS Code

Seide — Wed, 23 Sep 2026 21:48:01 GMT

← Older revision		Revision as of 21:48, 23 September 2026
(One intermediate revision by the same user not shown)
Line 7:		Line 7:

	For a list of active issues with the Remote - SSH extension, please see Microsoft's GitHub tracker [https://github.com/Microsoft/vscode-remote-release/labels/ssh here].		For a list of active issues with the Remote - SSH extension, please see Microsoft's GitHub tracker [https://github.com/Microsoft/vscode-remote-release/labels/ssh here].

			===Running VS Code on a Compute Node===
			VS Code with resource-intensive LSPs or AI/LLM extensions can cause usability issues on submission nodes. If you are using these extensions, we recommend setting up CPU-only compute jobs for your IDE.

			# SSH to your submission node.
			# Open a tmux session for your salloc command. salloc will only hold your allocation if you don't close your shell, so we use tmux to allow us to keep a persistent shell open on the submission node.
			# In your tmux session on the sumbission node, use <code>salloc</code> to request an allocation on a compute node. Once allocated, it will print hostname of the compute node which you were allocated.
			#* Example: <code>salloc --partition=tron --mem 4G --cpus-per-task 2</code>
			#* You can adjust the memory and CPUs as needed.
			#*: [[File:Salloc example.png\|thumb\|400px\|none\|Example of output from running salloc.]]
			# On your local machine, use the Remote-SSH plugin on VS Code to connect directly to the compute node.
			#: [[File:Add remote.png\|thumb\|400px\|none\|If the compute node is not defined, press the "+" to add a new remote.]][[File:Ssh command.png\|thumb\|400px\|none\|SSH command specifying compute name.]][[File:Update ssh config.png\|thumb\|400px\|none\|It will ask you which SSH config file it should use to store this remote. It's best to choose the one in your home directory.]][[File:Connect to remote.png\|thumb\|400px\|none\|With the compute node added, click the arrow to connect to the compute node.]]

	===Best Practices===		===Best Practices===

File:Connect to remote.png

Seide — Wed, 23 Sep 2026 21:34:04 GMT

Seide uploaded File:Connect to remote.png Connecting to a remote through VS Code.

New page

== Summary ==
Connecting to a remote through VS Code.

File:Update ssh config.png

Seide — Wed, 23 Sep 2026 21:32:09 GMT

Seide uploaded File:Update ssh config.png Prompt for adding host to SSH config.

New page

== Summary ==
Prompt for adding host to SSH config.

File:Ssh command.png

Seide — Wed, 23 Sep 2026 21:25:27 GMT

Seide uploaded File:Ssh command.png SSH command in VS Code.

New page

== Summary ==
SSH command in VS Code.

File:Add remote.png

Seide — Wed, 23 Sep 2026 21:20:32 GMT

Seide uploaded File:Add remote.png UI for adding a remote SSH host in VS Code.

New page

== Summary ==
UI for adding a remote SSH host in VS Code.

File:Salloc example.png

Seide — Wed, 23 Sep 2026 20:51:17 GMT

Seide uploaded File:Salloc example.png Example of allocating a job with salloc.

New page

== Summary ==
Example of allocating a job with salloc.

VS Code

Mbaney — Wed, 23 Sep 2026 13:40:25 GMT

← Older revision		Revision as of 13:40, 23 September 2026
(One intermediate revision by the same user not shown)
Line 4:		Line 4:

	==Cluster Usage==		==Cluster Usage==
	It can be convenient when using our [[SLURM]] computing clusters to open a connection to a [https://code.visualstudio.com/docs/remote/vscode-server VS Code Server] session on the submission node(s) that you have access to via VS Code's [https://code.visualstudio.com/docs/remote/ssh Remote - SSH extension]. Steps to set this up can be found [https://code.visualstudio.com/docs/remote/ssh#_installation here]. Use your UMIACS username and the [https://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name (FQDN)] of the submission node you want to connect to~~. Password authentication does not provide an option to save your password, so for convenience, you may want to set up an [[SSH/Keys \| SSH key]]~~.		It can be convenient when using our [[SLURM]] computing clusters to open a connection to a [https://code.visualstudio.com/docs/remote/vscode-server VS Code Server] session on the submission node(s) that you have access to via VS Code's [https://code.visualstudio.com/docs/remote/ssh Remote - SSH extension]. Steps to set this up can be found [https://code.visualstudio.com/docs/remote/ssh#_installation here]. Use your UMIACS username and the [https://en.wikipedia.org/wiki/Fully_qualified_domain_name fully qualified domain name (FQDN)] of the submission node you want to connect to.

	For a list of active issues with the Remote - SSH extension, please see Microsoft's GitHub tracker [https://github.com/Microsoft/vscode-remote-release/labels/ssh here].		For a list of active issues with the Remote - SSH extension, please see Microsoft's GitHub tracker [https://github.com/Microsoft/vscode-remote-release/labels/ssh here].
Line 26:		Line 26:
	VS Code comes bundled with [https://github.com/BurntSushi/ripgrep Ripgrep] as the default search program. Even if you aren't explicitly using the search functionality, VS Code will periodically run "rg --files", which will enumerate the list of files that Ripgrep would search. In workspaces with very large numbers of small files, this can result in degraded performance due to NFS overhead amplified by small file I/O. The following tips can ensure that Ripgrep does not significantly impact performance.		VS Code comes bundled with [https://github.com/BurntSushi/ripgrep Ripgrep] as the default search program. Even if you aren't explicitly using the search functionality, VS Code will periodically run "rg --files", which will enumerate the list of files that Ripgrep would search. In workspaces with very large numbers of small files, this can result in degraded performance due to NFS overhead amplified by small file I/O. The following tips can ensure that Ripgrep does not significantly impact performance.

	~~=====~~Keep data separate from code where possible~~=====~~		# '''Keep data separate from code where possible'''
	Make sure that datasets are kept outside of your VS Code workspace so that searches do not look through these directories. Alternatively, by default VS Code will not search files listed in a .ignore, .gitignore, or .rgignore file, so adding directories with datasets to one of these files is another option. Any directory with only binary data is a good candidate to add to this file. If you have changed your defaults or want to tweak these exclude settings further, these settings are found under "Settings->Features->Search".		#: Make sure that datasets are kept outside of your VS Code workspace so that searches do not look through these directories. Alternatively, by default VS Code will not search files listed in a .ignore, .gitignore, or .rgignore file, so adding directories with datasets to one of these files is another option. Any directory with only binary data is a good candidate to add to this file. If you have changed your defaults or want to tweak these exclude settings further, these settings are found under "Settings->Features->Search".
			# '''Limit maximum number of threads for searches'''
	~~=====~~Limit maximum number of threads for searches~~=====~~		#: By default, VS Code will automatically determine the number of threads to use when running Ripgrep. You can force a maximum number of threads under "Settings->Features->Search->Ripgrep: Max Threads" in order to limit the performance impact.
	By default, VS Code will automatically determine the number of threads to use when running Ripgrep. You can force a maximum number of threads under "Settings->Features->Search->Ripgrep: Max Threads" in order to limit the performance impact.

	====Clean up when done====		====Clean up when done====
	By default, VS Code Server will keep the processes used by your session active for a few hours after you disconnect. This takes away CPU time and memory from other users who are actively trying to use the nodes. There are two ways that you can ensure that your session gets closed in a reasonable amount of time.		By default, VS Code Server will keep the processes used by your session active for a few hours after you disconnect. This takes away CPU time and memory from other users who are actively trying to use the nodes. There are two ways that you can ensure that your session gets closed in a reasonable amount of time.

	~~=====~~Shortening the Remote-SSH Reconnection Grace Time~~=====~~		# '''Shortening the Remote-SSH Reconnection Grace Time'''
	You can configure the Remote-SSH extension to reduce this time to something reasonable (e.g. 5 minutes).		#: You can configure the Remote-SSH extension to reduce this time to something reasonable (e.g. 5 minutes).
			#: This can be done by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching "Remote-SSH: Settings".
	This can be done by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching "Remote-SSH: Settings".		#: [[File:VSCode-remotesshsettings.jpg\|alt=Under the Command Palette menu, "Remote-SSH: Settings" is searched.]]
			#: This will open a dialog box with settings for the Remote-SSH extension. From here, you can scroll down or search for "Remote.SSH: Reconnection Grace Time" and configure this to something reasonable.
	: [[File:VSCode-remotesshsettings.jpg\|alt=Under the Command Palette menu, "Remote-SSH: Settings" is searched.]]		#: [[File:VSCode-reconnectiongracetime.jpg\|alt=In the "Settings" dialog box, "Remote.SSH: Reconnection Grace Time" is overridden to 300 seconds.]]
			# '''Manually killing a remote VS Code server'''
	This will open a dialog box with settings for the Remote-SSH extension. From here, you can scroll down or search for "Remote.SSH: Reconnection Grace Time" and configure this to something reasonable.		#: You can also manually kill a remote VS Code server by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching "Kill VS Code Server on Host...".
			#: [[File:VSCode-killremote1.png\|alt=Under the Command Palette menu, "Kill VS Code Server on Host..." is searched.]]
	: [[File:VSCode-reconnectiongracetime.jpg\|alt=In the "Settings" dialog box, "Remote.SSH: Reconnection Grace Time" is overridden to 300 seconds.]]		#: Select the submission node you were using and click on it.
			#: [[File:VSCode-killremote2.png\|alt='nexus' is searched and a 2 submission nodes pop up as matching searches.]]
	~~=====~~Manually killing a remote VS Code server~~=====~~		#: Wait a few seconds and you should get a message confirming the command went through.
	You can also manually kill a remote VS Code server by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching "Kill VS Code Server on Host...".		#: [[File:VSCode-killremote3.png\|alt=Pop-up confirming the kill command went through.]]
			#: The next time you connect to the same submission node, you will have a fresh VS Code session on it.
	: [[File:VSCode-killremote1.png\|alt=Under the Command Palette menu, "Kill VS Code Server on Host..." is searched.]]

	Select the submission node you were using and click on it.

	: [[File:VSCode-killremote2.png\|alt='nexus' is searched and a 2 submission nodes pop up as matching searches.]]

	Wait a few seconds and you should get a message confirming the command went through.

	: [[File:VSCode-killremote3.png\|alt=Pop-up confirming the kill command went through.]]

	The next time you connect to the same submission node, you will have a fresh VS Code session on it.

	==Common Issues==		==Common Issues==

SecureShell/MFA

Mbaney — Fri, 18 Sep 2026 15:59:39 GMT

← Older revision		Revision as of 15:59, 18 September 2026
Line 88:		Line 88:

	==Considerations==		==Considerations==
	Since there is now an additional step to log in to our public-facing hosts, we would recommend using a [https://en.wikipedia.org/wiki/Terminal_multiplexer terminal multiplexer] such as ~~[[Screen]] or~~ [[Tmux]] to minimize the number of times you need to multi-factor authenticate. Terminal multiplexers allow you to start several different processes out of one terminal display, and also detach from and later reattach to each of the processes.		Since there is now an additional step to log in to our public-facing hosts, we would recommend using a [https://en.wikipedia.org/wiki/Terminal_multiplexer terminal multiplexer] such as [[Tmux]] to minimize the number of times you need to multi-factor authenticate. Terminal multiplexers allow you to start several different processes out of one terminal display, and also detach from and later reattach to each of the processes.

SecureShell

Mbaney — Fri, 18 Sep 2026 15:58:58 GMT

Long Running Processes

← Older revision		Revision as of 15:58, 18 September 2026
Line 109:		Line 109:

	==Long Running Processes==		==Long Running Processes==
	If you are dealing with a long running process that is inhibiting your ability to work regularly, you may want to run your processes inside a ~~screen~~ on the host that you're connecting to. This way, if the connection is dropped for any reason the ~~screen~~ session will automatically detach on the host and will continue running so that you can reattach it at a later time when you've connected again~~. Please see our documentation on [[Screen \| GNU Screen]] for more information~~.		If you are dealing with a long running process that is inhibiting your ability to work regularly, you may want to run your processes inside a [[Tmux]] session on the host that you're connecting to. This way, if the connection is dropped for any reason, the Tmux session will automatically detach on the host and will continue running so that you can reattach it at a later time when you've connected again.

	==Further Information==		==Further Information==
	* [https://www.openssh.com/ OpenSSH]		* [https://www.openssh.com/ OpenSSH]
	* [https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse OpenSSH on Windows]		* [https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse OpenSSH on Windows]

MonthlyMaintenanceWindow

Mbaney — Fri, 18 Sep 2026 00:53:22 GMT

← Older revision		Revision as of 00:53, 18 September 2026
Line 8:		Line 8:


	* '''September 17th 2026'''
	* October 22nd 2026		* October 22nd 2026
	* November 19th 2026		* November 19th 2026
Line 167:		Line 166:
	* July 23rd 2026		* July 23rd 2026
	* August 20th 2026		* August 20th 2026
			* September 17th 2026

WindowsServicing

Mbaney — Wed, 16 Sep 2026 18:06:22 GMT

Updating

← Older revision		Revision as of 18:06, 16 September 2026
Line 21:		Line 21:
	==Updating==		==Updating==
	Our [[Windows Patch Management]] automatically installs feature updates when we release them to UMIACS-managed devices. You will receive a notification to restart to install the feature update in the same way that other patches are installed. Please see that page for more details.		Our [[Windows Patch Management]] automatically installs feature updates when we release them to UMIACS-managed devices. You will receive a notification to restart to install the feature update in the same way that other patches are installed. Please see that page for more details.

			If for some reason your device is not automatically updated to the feature update mentioned above within a month or so of us releasing it, you can go to Windows Update on your device to see if it is available there and download/install it there if so. An example of what this might look like:

			[[File:Windows_Feature_Update.jpg\|600px]]

File:Windows Feature Update.jpg

Mbaney — Wed, 16 Sep 2026 18:04:48 GMT

Mbaney uploaded File:Windows Feature Update.jpg

New page

Orders

Mbaney — Fri, 11 Sep 2026 15:39:29 GMT

← Older revision		Revision as of 15:39, 11 September 2026
Line 27:		Line 27:
	**** Send one email per vendor. Otherwise, UMIACS staff will separate your request into different emails/[[Jira]] tickets after the fact.		**** Send one email per vendor. Otherwise, UMIACS staff will separate your request into different emails/[[Jira]] tickets after the fact.
	**** Specify if you want priority shipping per vendor. If no shipping speed is selected, the lowest cost shipping that still provides tracking will be used.		**** Specify if you want priority shipping per vendor. If no shipping speed is selected, the lowest cost shipping that still provides tracking will be used.
	** Specify ~~the purpose of~~ the purchase ~~(brief description)~~. If on sponsored funds such as federal grants, the description should also provide how the purchase relates to the purpose of the project.		** Specify a brief rationale for the purchase, i.e., why you are requesting it be bought. If on sponsored funds such as federal grants, the description should also provide how the purchase relates to the purpose of the project.

	==Option 3: Submitting order within [[Jira]] yourself==		==Option 3: Submitting order within [[Jira]] yourself==

Nexus/ClusterOSUpgrade

Mbaney — Wed, 09 Sep 2026 15:41:27 GMT

← Older revision		Revision as of 15:41, 9 September 2026
Line 2:		Line 2:
	UMIACS Technical Staff has finished upgrading the operating system version on all [[Nexus]] cluster nodes from [[RHEL \| Red Hat Enterprise Linux (RHEL)]] 8 to 9 as of Thursday 08/06/2026.		UMIACS Technical Staff has finished upgrading the operating system version on all [[Nexus]] cluster nodes from [[RHEL \| Red Hat Enterprise Linux (RHEL)]] 8 to 9 as of Thursday 08/06/2026.

	RHEL9 is still in the Full Support phase of its life cycle and introduces a newer major Linux kernel version and newer [https://www.gnu.org/software/libc glibc] version, improving compatibility with many newer software applications.		[https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9 RHEL9] is still in the Full Support phase of its life cycle and introduces a newer major Linux kernel version and newer [https://www.gnu.org/software/libc glibc] version, improving compatibility with many newer software applications.

	==Scheduling==		==Scheduling==

← Older revision		Revision as of 15:53, 25 September 2026
(5 intermediate revisions by the same user not shown)
Line 1:		Line 1:
	Submission nodes are intended for ~~users~~ to submit jobs to the Nexus cluster. User interactivity is critical here, and while some of these submission nodes have a decent amount of cores and memory, highly-intensive computational jobs should not be run on these nodes. We have minimal resource restrictions in place at the moment, but we may explore further CPU/memory restrictions ~~in the future~~. For the time being, be a good neighbor!		Submission nodes are intended for you to submit jobs to the Nexus cluster. User interactivity is critical here, and while some of these submission nodes have a decent amount of cores and memory, highly-intensive computational jobs should not be run on these nodes. We have minimal resource restrictions in place at the moment, but we may explore further CPU/memory restrictions if need dictates. For the time being, please be a good neighbor!

	In general, we expect that ~~users on these nodes~~ do not use more than 1-2GB of memory at a time and do not sustain >=100% CPU usage (at least 1 core fully utilized) for extended periods of time. Utilizing more than 1 core is fine for bursty workloads, but sustained high CPU utilization can lead to issues with interactivity, and these issues can be drastically amplified if there is also memory contention on the node, as swapping memory requires CPU time.		In general, we expect that you do not use more than 2GB of memory at a time and do not sustain >=100% CPU usage (at least one core fully utilized) for extended periods of time. Utilizing more than one core is fine for bursty workloads, but sustained high CPU utilization can lead to issues with interactivity, and these issues can be drastically amplified if there is also memory contention on the node, as swapping memory requires CPU time.

	=Examples=		=Examples=
Line 7:		Line 7:
	==Appropriate submission node uses==		==Appropriate submission node uses==

	* ~~Job~~ submission		* Running Slurm job submission commands: <code>srun</code>, <code>salloc</code>, <code>sbatch</code>
	* Using as a SSH jump host ~~for~~ other hosts		* Using as a SSH jump host to connect to other hosts
	* ~~Basic~~ code editing in editors with minimal extensions (e.g. emacs, nano, vim, neovim without an LSP).		* Performing basic code editing in editors with minimal extensions, e.g., emacs, nano, vim, neovim without an LSP.

	==Appropriate submission node uses, with caveats==		==Appropriate submission node uses, with caveats==
Line 15:		Line 15:
	These kinds of workloads can be run on submission nodes, but if they are incorrectly configured, they can affect interactivity of the nodes. If we notice repeated behavior like this, we may reach out to you to ask about your environment and suggest ways to lower resource utilization.		These kinds of workloads can be run on submission nodes, but if they are incorrectly configured, they can affect interactivity of the nodes. If we notice repeated behavior like this, we may reach out to you to ask about your environment and suggest ways to lower resource utilization.

	* IDEs can be fine, but keep in mind which extensions you install. Some extensions/behaviors may use more memory/CPU than you realize.		* IDEs can be fine, but keep in mind which extensions you install. Some extensions/behaviors may use more memory/CPU than you realize, especially AI/LLM ones.
	** We have some [[VS_Code\|guidance for VS Code and its forks]].		** We have some [[VS_Code\|guidance for VS Code and its forks]]. If you are using AI/LLM extensions, please consider running your IDE on a compute node, which there are instructions for doing on the linked page.
	* For smaller projects, code compilation can be fine. If a project takes longer than 30 seconds to compile, please ensure compilation is limited to a single thread, or consider compiling the code in a Slurm job on one of the dedicated CPU nodes (we suggest using the scavenger partition).		* For smaller projects, code compilation can be fine. If a project takes longer than 30 seconds to compile, please ensure compilation is limited to a single thread, or consider compiling the code in a Slurm job on one of the dedicated CPU nodes - we suggest using the scavenger partition.
	** Depending on a project's file structure, code compilation can be highly I/O dependent, which can also impact user interactivity.		** Depending on a project's file structure, code compilation can be highly I/O dependent, which can also impact user interactivity.
	* Setting up environments with user package managers (e.g. pip, npm, conda/mamba)		* Setting up environments with user package managers, e.g., pip, npm, conda/mamba.
	** The resource usage of package managers mostly depends on the specific packages being installed. Complex environments can take a while with package managers like conda/mamba due to dependency resolution. Other packages aren't actually binary releases but will instead compile projects transparently to ~~the user~~. For these reasons, we suggest that non-trivial environments should be set up in a Slurm job (we suggest using the scavenger partition).		** The resource usage of package managers mostly depends on the specific packages being installed. Complex environments can take a while with package managers like conda/mamba due to dependency resolution. Other packages aren't actually binary releases but will instead compile projects transparently to you. For these reasons, we suggest that non-trivial environments should be set up in a Slurm job - we suggest using the scavenger partition.
	* Running lightweight programs to interact with Slurm jobs currently running on the cluster.		* Running lightweight programs to interact with Slurm jobs currently running on the cluster.

	==Inappropriate submission node uses==		==Inappropriate submission node uses==

	If tech staff notices processes with the following behavior and node interactivity is affected, <b>we may kill these processes</b>. If ~~a user~~ repeatedly ~~causes~~ issues, further action may be taken on ~~their~~ account.		If tech staff notices processes with the following behavior and node interactivity is affected, <b>we may kill these processes</b>. If you repeatedly cause issues, further action may be taken on your account.

	* Compiling large projects using all threads on a submission node.		* Compiling large projects using all threads on a submission node.