https://wiki.umiacs.umd.edu/umiacs/api.php?action=feedcontributions&feedformat=atom&user=Mbaney 2026-10-01T21:11:21Z User contributions MediaWiki 1.43.9 https://wiki.umiacs.umd.edu/umiacs/index.php?title=MonthlyMaintenanceWindow&diff=13427 2026-10-01T18:40:16Z

<p>Mbaney: </p> <hr /> <div>[[HelpDesk | UMIACS staff]] takes a monthly maintenance window to patch and reboot all UMIACS-supported hosts and services. This provides a way for staff to ensure security updates are installed and applied on the numerous different platforms and appliances that UMIACS runs.<br /> <br /> The window for each month is calculated by adding 9 days to [https://en.wikipedia.org/wiki/Patch_Tuesday Microsoft's Patch Tuesday] to allow for enough time to marshal patches released that month from Microsoft, Red Hat, Apple, and other OS and application vendors and have enough time to get systems prepared to reboot. This translates to the window being on the '''Thursday that occurs between the 17th and the 23rd (inclusive)''' of each month. The window lasts from '''5pm-8pm'''.<br /> <br /> [[Nexus]] will always have a reservation in place from 4:45pm-8pm on the day of the upcoming window to prevent jobs from being scheduled on compute nodes. The 15-minute addition before the start of the window is to allow jobs to fully end. Any job submitted before the reservation begins that has a time limit that would run into the reservation will be held until at least the end of the reservation - 8pm on the day of the window. This is to prevent issues with jobs failing to end properly causing delays in work we have scheduled during the window.<br /> <br /> A list of upcoming maintenance windows is as follows, with the next one in bold. Again, the window is on the '''Thursday that occurs between the 17th and the 23rd (inclusive)''' of each month, and lasts from '''5pm-8pm'''.<br /> <br /> <br /> * '''October 9th-13th (datacenter, including Nexus, due to cooling outage)''' and '''October 22nd 2026 (non-datacenter)'''<br /> * November 19th 2026<br /> * December 17th 2026<br /> <br /> ==Archives==<br /> * January 17th 2013 - BEGIN time of 8pm-12am for this window through February 20th 2020<br /> * February 21st 2013<br /> * March 21st 2013<br /> * April 18th 2013<br /> * May 23rd 2013<br /> * June 20th 2013<br /> * July 18th 2013<br /> * August 22nd 2013<br /> * September 19th 2013<br /> * October 17th 2013<br /> * December 19th 2013<br /> * January 23rd 2014<br /> * February 20th 2014<br /> * March 20th 2014<br /> * April 17th 2014<br /> * May 22nd 2014<br /> * June 19th 2014<br /> * July 17th 2014<br /> * August 21st 2014<br /> * September 18th 2014<br /> * October 23rd 2014<br /> * November 20th 2014<br /> * December 18th 2014<br /> * January 22nd 2015<br /> * February 19th 2015<br /> * March 19th 2015<br /> * May 21st 2015<br /> * June 18th 2015<br /> * July 23rd 2015<br /> * August 20th 2015<br /> * September 17th 2015<br /> * October 22nd 2015<br /> * November 19th 2015<br /> * December 17th 2015<br /> * January 21st 2016<br /> * February 18th 2016<br /> * March 12th 2016 (Adjusted date for AVW power outage)<br /> * April 21st 2016<br /> * May 19th 2016<br /> * June 23rd 2016<br /> * July 21st 2016<br /> * August 18th 2016<br /> * September 22nd 2016<br /> * October 20th 2016<br /> * November 17th 2016<br /> * December 22nd 2016<br /> * January 19th 2017<br /> * February 23rd 2017<br /> * March 23rd 2017<br /> * April 20th 2017<br /> * May 18th 2017<br /> * June 22nd 2017<br /> * July 20th 2017<br /> * August 17th 2017<br /> * September 21st 2017<br /> * October 19th 2017<br /> * December 21st 2017<br /> * January 18th 2018<br /> * February 22nd 2018<br /> * March 22nd 2018<br /> * April 19th 2018<br /> * May 17th 2018<br /> * June 21st 2018<br /> * July 19th 2018<br /> * August 23rd 2018<br /> * September 20th 2018<br /> * October 18th 2018<br /> * December 20th 2018<br /> * January 24th 2019<br /> * February 21st 2019<br /> * April 18th 2019<br /> * May 23rd 2019<br /> * June 20th 2019<br /> * July 18th 2019<br /> * August 22nd 2019<br /> * September 19th 2019<br /> * October 17th 2019<br /> * November 21st 2019<br /> * December 19th 2019<br /> * January 23rd 2020<br /> * February 20th 2020<br /> * April 23rd 2020 - BEGIN time of 5pm-7pm for this window through August 19th 2021<br /> * June 18th 2020<br /> * July 23rd 2020<br /> * August 20th 2020<br /> * September 17th 2020<br /> * October 22nd 2020<br /> * November 19th 2020<br /> * December 17th 2020<br /> * January 21st 2021<br /> * February 18th 2021<br /> * March 25th 2021 (Adjusted date for extended Spring Break)<br /> * April 22nd 2021<br /> * May 20th 2021<br /> * June 17th 2021<br /> * July 22nd 2021<br /> * August 19th 2021<br /> * September 23rd 2021 - BEGIN time of 5pm-8pm for this window and all others below<br /> * October 21st 2021<br /> * November 18th 2021<br /> * January 20th 2022<br /> * February 17th 2022<br /> * March 24th 2022 (Adjusted date for Spring Break)<br /> * April 21st 2022<br /> * May 19th 2022<br /> * June 23rd 2022<br /> * July 21st 2022<br /> * August 18th 2022<br /> * September 22nd 2022<br /> * October 20th 2022<br /> * November 17th 2022<br /> * January 19th 2023<br /> * February 23rd 2023<br /> * April 20th 2023<br /> * May 18th 2023<br /> * June 22nd 2023<br /> * July 20th 2023<br /> * August 17th 2023<br /> * September 21st 2023<br /> * October 19th 2023<br /> * December 20th 2023 (Adjusted date for early Winter Break)<br /> * January 18th 2024<br /> * February 22nd 2024<br /> * March 21st 2024<br /> * April 18th 2024<br /> * May 23th 2024<br /> * June 20th 2024<br /> * July 18th 2024<br /> * August 22nd 2024<br /> * September 19th 2024<br /> * October 17th 2024<br /> * November 21st 2024<br /> * December 19th 2024<br /> * January 23rd 2025<br /> * February 20th 2025<br /> * March 20th 2025<br /> * April 17th 2025<br /> * May 22nd 2025<br /> * June 19th 2025<br /> * July 17th 2025<br /> * August 21st 2025<br /> * September 18th 2025<br /> * October 23rd 2025<br /> * November 20th 2025<br /> * December 18th 2025<br /> * January 22nd 2026<br /> * February 19th 2026<br /> * March 19th 2026<br /> * April 23rd 2026<br /> * May 28th 2026 (Adjusted date for CIO-imposed network change freeze)<br /> * June 18th 2026<br /> * July 23rd 2026<br /> * August 20th 2026<br /> * September 17th 2026</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=MonthlyMaintenanceWindow&diff=13426 2026-09-30T20:23:40Z

<p>Mbaney: </p> <hr /> <div>[[HelpDesk | UMIACS staff]] takes a monthly maintenance window to patch and reboot all UMIACS-supported hosts and services. This provides a way for staff to ensure security updates are installed and applied on the numerous different platforms and appliances that UMIACS runs.<br /> <br /> The window for each month is calculated by adding 9 days to [https://en.wikipedia.org/wiki/Patch_Tuesday Microsoft's Patch Tuesday] to allow for enough time to marshal patches released that month from Microsoft, Red Hat, Apple, and other OS and application vendors and have enough time to get systems prepared to reboot. This translates to the window being on the '''Thursday that occurs between the 17th and the 23rd (inclusive)''' of each month. The window lasts from '''5pm-8pm'''.<br /> <br /> [[Nexus]] will always have a reservation in place from 4:45pm-8pm on the day of the upcoming window to prevent jobs from being scheduled on compute nodes. The 15-minute addition before the start of the window is to allow jobs to fully end. Any job submitted before the reservation begins that has a time limit that would run into the reservation will be held until at least the end of the reservation - 8pm on the day of the window. This is to prevent issues with jobs failing to end properly causing delays in work we have scheduled during the window.<br /> <br /> A list of upcoming maintenance windows is as follows, with the next one in bold. Again, the window is on the '''Thursday that occurs between the 17th and the 23rd (inclusive)''' of each month, and lasts from '''5pm-8pm'''.<br /> <br /> <br /> * '''October 22nd 2026'''<br /> * November 19th 2026<br /> * December 17th 2026<br /> <br /> ==Archives==<br /> * January 17th 2013 - BEGIN time of 8pm-12am for this window through February 20th 2020<br /> * February 21st 2013<br /> * March 21st 2013<br /> * April 18th 2013<br /> * May 23rd 2013<br /> * June 20th 2013<br /> * July 18th 2013<br /> * August 22nd 2013<br /> * September 19th 2013<br /> * October 17th 2013<br /> * December 19th 2013<br /> * January 23rd 2014<br /> * February 20th 2014<br /> * March 20th 2014<br /> * April 17th 2014<br /> * May 22nd 2014<br /> * June 19th 2014<br /> * July 17th 2014<br /> * August 21st 2014<br /> * September 18th 2014<br /> * October 23rd 2014<br /> * November 20th 2014<br /> * December 18th 2014<br /> * January 22nd 2015<br /> * February 19th 2015<br /> * March 19th 2015<br /> * May 21st 2015<br /> * June 18th 2015<br /> * July 23rd 2015<br /> * August 20th 2015<br /> * September 17th 2015<br /> * October 22nd 2015<br /> * November 19th 2015<br /> * December 17th 2015<br /> * January 21st 2016<br /> * February 18th 2016<br /> * March 12th 2016 (Adjusted date for AVW power outage)<br /> * April 21st 2016<br /> * May 19th 2016<br /> * June 23rd 2016<br /> * July 21st 2016<br /> * August 18th 2016<br /> * September 22nd 2016<br /> * October 20th 2016<br /> * November 17th 2016<br /> * December 22nd 2016<br /> * January 19th 2017<br /> * February 23rd 2017<br /> * March 23rd 2017<br /> * April 20th 2017<br /> * May 18th 2017<br /> * June 22nd 2017<br /> * July 20th 2017<br /> * August 17th 2017<br /> * September 21st 2017<br /> * October 19th 2017<br /> * December 21st 2017<br /> * January 18th 2018<br /> * February 22nd 2018<br /> * March 22nd 2018<br /> * April 19th 2018<br /> * May 17th 2018<br /> * June 21st 2018<br /> * July 19th 2018<br /> * August 23rd 2018<br /> * September 20th 2018<br /> * October 18th 2018<br /> * December 20th 2018<br /> * January 24th 2019<br /> * February 21st 2019<br /> * April 18th 2019<br /> * May 23rd 2019<br /> * June 20th 2019<br /> * July 18th 2019<br /> * August 22nd 2019<br /> * September 19th 2019<br /> * October 17th 2019<br /> * November 21st 2019<br /> * December 19th 2019<br /> * January 23rd 2020<br /> * February 20th 2020<br /> * April 23rd 2020 - BEGIN time of 5pm-7pm for this window through August 19th 2021<br /> * June 18th 2020<br /> * July 23rd 2020<br /> * August 20th 2020<br /> * September 17th 2020<br /> * October 22nd 2020<br /> * November 19th 2020<br /> * December 17th 2020<br /> * January 21st 2021<br /> * February 18th 2021<br /> * March 25th 2021 (Adjusted date for extended Spring Break)<br /> * April 22nd 2021<br /> * May 20th 2021<br /> * June 17th 2021<br /> * July 22nd 2021<br /> * August 19th 2021<br /> * September 23rd 2021 - BEGIN time of 5pm-8pm for this window and all others below<br /> * October 21st 2021<br /> * November 18th 2021<br /> * January 20th 2022<br /> * February 17th 2022<br /> * March 24th 2022 (Adjusted date for Spring Break)<br /> * April 21st 2022<br /> * May 19th 2022<br /> * June 23rd 2022<br /> * July 21st 2022<br /> * August 18th 2022<br /> * September 22nd 2022<br /> * October 20th 2022<br /> * November 17th 2022<br /> * January 19th 2023<br /> * February 23rd 2023<br /> * April 20th 2023<br /> * May 18th 2023<br /> * June 22nd 2023<br /> * July 20th 2023<br /> * August 17th 2023<br /> * September 21st 2023<br /> * October 19th 2023<br /> * December 20th 2023 (Adjusted date for early Winter Break)<br /> * January 18th 2024<br /> * February 22nd 2024<br /> * March 21st 2024<br /> * April 18th 2024<br /> * May 23th 2024<br /> * June 20th 2024<br /> * July 18th 2024<br /> * August 22nd 2024<br /> * September 19th 2024<br /> * October 17th 2024<br /> * November 21st 2024<br /> * December 19th 2024<br /> * January 23rd 2025<br /> * February 20th 2025<br /> * March 20th 2025<br /> * April 17th 2025<br /> * May 22nd 2025<br /> * June 19th 2025<br /> * July 17th 2025<br /> * August 21st 2025<br /> * September 18th 2025<br /> * October 23rd 2025<br /> * November 20th 2025<br /> * December 18th 2025<br /> * January 22nd 2026<br /> * February 19th 2026<br /> * March 19th 2026<br /> * April 23rd 2026<br /> * May 28th 2026 (Adjusted date for CIO-imposed network change freeze)<br /> * June 18th 2026<br /> * July 23rd 2026<br /> * August 20th 2026<br /> * September 17th 2026</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=MailmanListAdmin&diff=13425 2026-09-25T16:31:59Z

<p>Mbaney: </p> <hr /> <div>==Mailman List Administration==<br /> The full documentation can be found at (among other places) the Mailman administrators guide: https://www.gnu.org/software/mailman/<br /> <br /> Once UMIACS staff has created your list, they will tell you what the password is for managing this list. You'll need this password to do various list management things such as add/remove users, approve user subscription or postings for restricted lists, and tailor the list.<br /> <br /> If staff was provided with a list of initial subscribers, these people will have already been subscribed. Tell your users that if they'd like to subscribe, they need only go to<br /> <br /> https://lists.umiacs.umd.edu/mailman/listinfo/LISTNAME<br /> <br /> even if the list is private (not advertised or listed).<br /> <br /> They can also subscribe/unsubscribe by email by sending to<br /> <br /> LISTNAME-subscribe and LISTNAME-unsubscribe<br /> <br /> 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.<br /> <br /> ===Managing a List===<br /> To manage your list, go to:<br /> <br /> https://lists.umiacs.umd.edu/mailman/admin/LISTNAME<br /> <br /> 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.<br /> <br /> * Just because you are the list administrator doesn't mean you're subscribed to (or have to be subscribed to) the list.<br /> * Messages sent out aren't necessarily delivered immediately; it could take up to 5 minutes.<br /> <br /> ====Membership Management====<br /> https://lists.umiacs.umd.edu/mailman/admin/LISTNAME/members<br /> <br /> This is where you can subscribe and unsubscribe users, hide their email addresses, and more.<br /> * To subscribe other people, on this form, enter their addresses in the text window under the &quot;Mass Subscription&quot; section. Please note that if the user you are adding has a UMD address, you should use that address in order to comply with the [https://umd.service-now.com/itsupport/?sys_kb_id=6b102078dbbec8d06aa4151748961927&amp;id=kb_article_view&amp;sysparm_rank=2&amp;sysparm_tsqueryId=c11ba448db4788906aa4151748961904#institutional-email-standard Institutional email standard].<br /> * If a user goes on vacation, you can change the option to &quot;nomail&quot; for them on this form turning off mailing to that individual until he/she returns. Of course, users can do this themselves as well.<br /> * If a user forgets their password, clicking on the user's email address on this form allows you to send them an email message containing their password.<br /> <br /> ====Privacy options====<br /> https://lists.umiacs.umd.edu/mailman/admin/LISTNAME/privacy<br /> <br /> This is where you can specify whether or not the list is visible to the world, whether or not administrative approval is required to subscribe to the list, who can view the list of subscribers, who can post to the list (is it open or moderated?), and more.<br /> <br /> ====Archiving Options====<br /> https://lists.umiacs.umd.edu/mailman/admin/LISTNAME/archive<br /> <br /> This is where you can choose whether or not to archive messages send to the list. By default, messages are archived and are available only to subscribers of the list using their subscribing password at https://lists.umiacs.umd.edu/mailman/private/LISTNAME. You can change this to make messages available to the public or turn off archiving entirely. '''Archives are not searchable.'''<br /> <br /> ===General Settings===<br /> Most of the defaults for lists are probably fine but a number of them bear special mention. <br /> <br /> Options under ''Subscribing'' under &quot;Privacy options&quot;:<br /> * By default, no one can see the list.<br /> ** If this is not the behavior you want, change the setting on the first item &quot;Advertise this list when people ask what lists are on this machine?&quot; from NO to YES, and then &quot;Submit Your Changes&quot; on the bottom of the page. Note that even if users can't see the list, they can still subscribe (or try to subscribe). They simply need to know the URL.<br /> * By default, anyone can subscribe to the list. (To ensure that someone can't subscribe someone else as a prank, Mailman sends a confirm email message to the users asking something like, &quot;You have been subscribed to.... Are you sure you want to subscribe? Just REPLYing to this message will subscribe you&quot;).<br /> ** If this is not the behavior you want, change the setting on the second item &quot;What steps are required for subscription?&quot; and click &quot;Require approval&quot; or &quot;Confirm and approve&quot; and then &quot;Submit Your Changes&quot; on the bottom of the page. Approval means that you, as the list administrator, will get a message saying USER@HOST wants to subscribe. You can then approve or discard their request.<br /> <br /> Option under ''Membership exposure'' under &quot;Privacy options&quot;:<br /> * By default, only list members can see the email addresses of other list members. '''Users can hide their own addresses from their list subscription page'''. Likewise, you can hide some users and not others from the &quot;Membership Management&quot; page.<br /> ** If you want to broadly change visibility for all users, change the setting on the first item &quot;Who can view subscription list?&quot; and click either &quot;Anyone&quot; or &quot;List admin only&quot; and then &quot;Submit Your Changes&quot; on the bottom of the page.<br /> <br /> ===Moderated Lists===<br /> ====Setup====<br /> If you want your list to be moderated (i.e. ONLY you and/or a few others can post to it), this can be set at the bottom of the &quot;Membership Management&quot; --&gt; &quot;Membership List&quot; page. Make sure to also set this for all new members under &quot;Privacy options&quot; --&gt; &quot;Sender filters&quot;. If moderation is set, make sure the list admin (and/or whomever you want to be able to send to the list) has their moderation bit turned off.<br /> <br /> List admins can add moderators to a list by entering their email addresses in the &quot;The list moderator email addresses. Multiple moderator addresses, each on separate line is okay.&quot; box on the &quot;General Options&quot; page of the list's admin interface:<br /> :[[File:Mailmanmoderators.png|alt=Screenshot of admin interface highlighting the previously described box]]<br /> <br /> As soon as the first moderator is added to the list, a list admin should set the moderator password and communicate it to the initial moderator(s). This password can only be changed by a list admin. It does not give full administrative access to the list.<br /> <br /> ====For list moderators====<br /> Moderators and administrators will receive an email similar to the following if a message is being held for moderation:<br /> :[[File:Moderationemail.png|alt=Screen of example email to expect if something is held for moderation]]<br /> <br /> The provided URL can also be visited at any time to view the queue of messages pending moderation:<br /> <br /> https://lists.umiacs.umd.edu/mailman/admindb/LISTNAME<br /> <br /> From here, if there are one or more messages pending moderation, you will see a summary of the messages broken down per-sender. Please note that the addresses in these screenshots are hidden for privacy, but will appear on the actual moderation page.<br /> <br /> There are two ways messages from senders may appear on this interface, depending on whether or not the sender is a member of the list:<br /> * If the sender is a member of the list (but their moderation bit is on):<br /> *: [[File:Moderatedmember_held.png|alt=Screenshot of message pending moderation when the sender is a member of the list it is being sent to]]<br /> * If the sender is not a member of the list:<br /> *: [[File:Nonmember_held.png|alt=Screenshot of message pending moderation when the sender is not a member of the list it is being sent to]]<br /> <br /> From these windows, you can choose an action (Defer, Accept, Reject, Discard) for all messages from a specific sender via the radio buttons in the left sub-window, or handle individual messages by clicking on the [#] hyperlinks next to each subject line.<br /> <br /> The key difference between the two categories of held messages (from a moderated member vs. from a non-member) is how you can handle future messages from the respective senders in the future:<br /> * For moderated members, you can choose the &quot;Clear this member's moderate flag&quot; option in the window for that member to automatically allow future messages from them to the list. <br /> * For non-members, you can choose to either add the sender's email address to one of the automatic filters for non-members (Accept, Hold, Reject, or Discard) to automatically action their messages in the future. There is also an option to ban the sender's email address from subscribing to the list if you see fit.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=VS_Code&diff=13424 2026-09-25T16:12:21Z

<p>Mbaney: /* Running VS Code on a Compute Node */</p> <hr /> <div>[https://code.visualstudio.com/ Visual Studio (VS) Code] is a multi-platform source-code editor developed by Microsoft. It can be used with a variety of programming languages and can have its base functionality extended through extensions available via its [https://marketplace.visualstudio.com/vscode marketplace]. The base editor itself is free, but some extensions may require paid subscriptions.<br /> <br /> There are also forks/open source alternatives of VS Code, such as [https://www.cursor.com Cursor] or [https://vscodium.com/ VSCodium]. The same general principals below apply to these editors as well.<br /> <br /> ==Cluster Usage==<br /> 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.<br /> <br /> 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].<br /> <br /> ===Best Practices===<br /> Because of the multi-tenant nature of our submission nodes, using the Remote - SSH extension to connect to a VS Code Server running on a submission node can have adverse affects on other users simultaneously using the submission nodes if not properly managed. The following is a list of &quot;best practices&quot; that we ask you please follow to minimize the chance of impacting others on submission nodes. We have compiled the list through observation as well as through discussion with users.<br /> <br /> ====Use only as a code editor====<br /> VS Code can perform many common file management operations, such as moving, copying, or deleting files or directories. However, the overhead of providing progress updates / status messages through VS Code's UI can cause load spikes that result in other system-level and user processes on the submission node slowing down. This is especially the case if operating on thousands to millions of small image or video files. In extreme cases, it can seem as though the submission node is wholly unresponsive.<br /> <br /> The best way to combat this is to use VS Code as just a code editor as strictly as you can (meaning creating new and/or editing existing source code files only). Use standard command-line programs such as &lt;code&gt;mv&lt;/code&gt;/&lt;code&gt;cp&lt;/code&gt;/&lt;code&gt;rm&lt;/code&gt; in VS Code's terminal window or a separate application's terminal window for local file management instead, or use the techniques advertised [[LocalDataTransfer | here]] for larger data transfers between nodes.<br /> <br /> ====Do not open large files====<br /> Files that you open in VS Code's text editor on a remote machine through the Remote - SSH extension are loaded entirely into RAM on the remote machine. Because of the persistence of VS Code Server processes, opening several unique files may result in them all remaining in RAM for extended periods of time even if you no longer have tabs open for them in the Tab Bar.<br /> <br /> As such, please refrain from opening large files (more than a few MB) in VS Code itself on submission nodes. Use a lighter-weight command-line based text editor such as [https://www.vim.org vim] or otherwise in VS Code's terminal window or a separate application's terminal window for local file editing instead.<br /> <br /> If you absolutely need to open one or more large files for a very brief period of time on a submission node, please clean up your server session on that node (see below section) as soon as possible when done.<br /> <br /> ====Ripgrep====<br /> 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 &quot;rg --files&quot;, 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.<br /> <br /> # '''Keep data separate from code where possible'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search&quot;.<br /> # '''Limit maximum number of threads for searches'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search-&gt;Ripgrep: Max Threads&quot; in order to limit the performance impact.<br /> <br /> ====Clean up when done====<br /> 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.<br /> <br /> # '''Shortening the Remote-SSH Reconnection Grace Time'''<br /> #: You can configure the Remote-SSH extension to reduce this time to something reasonable (e.g. 5 minutes).<br /> #: This can be done by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching &quot;Remote-SSH: Settings&quot;.<br /> #: [[File:VSCode-remotesshsettings.jpg|alt=Under the Command Palette menu, &quot;Remote-SSH: Settings&quot; is searched.]]<br /> #: This will open a dialog box with settings for the Remote-SSH extension. From here, you can scroll down or search for &quot;Remote.SSH: Reconnection Grace Time&quot; and configure this to something reasonable.<br /> #: [[File:VSCode-reconnectiongracetime.jpg|alt=In the &quot;Settings&quot; dialog box, &quot;Remote.SSH: Reconnection Grace Time&quot; is overridden to 300 seconds.]]<br /> # '''Manually killing a remote VS Code server'''<br /> #: 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 &quot;Kill VS Code Server on Host...&quot;.<br /> #: [[File:VSCode-killremote1.png|alt=Under the Command Palette menu, &quot;Kill VS Code Server on Host...&quot; is searched.]]<br /> #: Select the submission node you were using and click on it.<br /> #: [[File:VSCode-killremote2.png|alt='nexus' is searched and a 2 submission nodes pop up as matching searches.]]<br /> #: Wait a few seconds and you should get a message confirming the command went through.<br /> #: [[File:VSCode-killremote3.png|alt=Pop-up confirming the kill command went through.]]<br /> #: The next time you connect to the same submission node, you will have a fresh VS Code session on it.<br /> <br /> ===Running VS Code on a Compute Node===<br /> 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.<br /> <br /> # SSH to your submission node.<br /> # Open a [[Tmux]] session for your salloc command. salloc will only hold your allocation if you don't close your shell, so tmux is a convenient way to keep a persistent shell open on the submission node.<br /> # In your tmux session on the submission node, use &lt;code&gt;salloc&lt;/code&gt; to request an allocation on a compute node. Once allocated, it will print the hostname of the compute node you were allocated.<br /> #* Example: &lt;code&gt;salloc --cpus-per-task=2 --mem=4G&lt;/code&gt;<br /> #* You can adjust the CPUs, memory, and time limit as needed.<br /> #* Without any other arguments, this allocation will be under the 'nexus' account on the '[[Nexus/Tron | tron]]' partition, subject to the 'default' QoS resource limits. If you need resources beyond what the default QoS allows, you can adjust the account/partition/QoS assigned to the allocation as you can with any other job.<br /> #*: [[File:Salloc example.png|thumb|400px|none|Example of output from running salloc.]]<br /> # On your local machine, use the Remote-SSH plugin on VS Code to connect directly to the compute node.<br /> #: [[File:Add remote.png|thumb|400px|none|If the compute node is not defined, press the &quot;+&quot; 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.]]<br /> # Once connected, begin using VS Code on the compute node however you would like - your allocation is constrained to the amount of CPUs and memory requested, so it will not affect other users' jobs / allocations running on the node. If you find that your processes are being killed within your allocation due to running out of memory, try requesting more memory for your next allocation.<br /> <br /> ==Common Issues==<br /> If you are having trouble [[SSH]]'ing to a submission node with VS Code, check if your home directory is full.<br /> <br /> # Connect to one of your Nexus submission nodes via [[SSH]] '''not''' using VS Code.<br /> # Navigate to your home directory. &lt;pre&gt;cd ~&lt;/pre&gt;<br /> # Check if it is full. &lt;pre&gt;df -h .&lt;/pre&gt;<br /> # If it is full (Avail 0), delete some files to free up at least ~100MB of space. &lt;pre&gt;Filesystem Size Used Avail Use% Mounted on&amp;#10;data.isilon.umiacs.umd.edu:/ifs/umiacs/homes 30G 30G 0 100% /fs/nfshomes&lt;/pre&gt;<br /> # Try connecting with VS Code again.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=Nexus/Submission_Node_Policy&diff=13423 2026-09-25T15:53:06Z

<p>Mbaney: </p> <hr /> <div>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!<br /> <br /> In general, we expect that you do not use more than 2GB of memory at a time and do not sustain &gt;=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.<br /> <br /> =Examples=<br /> <br /> ==Appropriate submission node uses==<br /> <br /> * Running Slurm job submission commands: &lt;code&gt;srun&lt;/code&gt;, &lt;code&gt;salloc&lt;/code&gt;, &lt;code&gt;sbatch&lt;/code&gt;<br /> * Using as a SSH jump host to connect to other hosts<br /> * Performing basic code editing in editors with minimal extensions, e.g., emacs, nano, vim, neovim without an LSP.<br /> <br /> ==Appropriate submission node uses, with caveats==<br /> <br /> 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.<br /> <br /> * 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.<br /> ** 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.<br /> * 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.<br /> ** Depending on a project's file structure, code compilation can be highly I/O dependent, which can also impact user interactivity.<br /> * Setting up environments with user package managers, e.g., pip, npm, conda/mamba.<br /> ** 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.<br /> * Running lightweight programs to interact with Slurm jobs currently running on the cluster.<br /> <br /> ==Inappropriate submission node uses==<br /> <br /> If tech staff notices processes with the following behavior and node interactivity is affected, &lt;b&gt;we may kill these processes&lt;/b&gt;. If you repeatedly cause issues, further action may be taken on your account.<br /> <br /> * Compiling large projects using all threads on a submission node.<br /> * Running nontrivial computation requiring significant CPU and/or memory resources.<br /> <br /> =Advice for monitoring/reducing CPU/memory utilization=<br /> <br /> Here is some general guidance for tracking your resource utilization on a node, as well as some practices you can follow to slightly reduce CPU usage of certain tasks.<br /> <br /> * `top`<br /> ** By default, `top` sorts by %CPU, but you can sort by %MEM by pressing &quot;M&quot; (Shift + &quot;m&quot;).<br /> ** You can limit it to show only processes from your user by starting it with `-u $USER`<br /> ** VIRT memory usage doesn't mean too much, as oftentimes programs will request way more memory than they actually need, and the kernel may not actually give them this memory until it is actually required. RSS memory is the actual amount of memory used by a process at a given point. If there is no suffix, the reported value is in KB.<br /> * /sys/fs/cgroup/memory/user.slice/user-$UID_NUMBER.slice/memory.usage_in_bytes<br /> ** This is the current combined memory usage of all processes running under your user.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=Nexus/Submission_Node_Policy&diff=13422 2026-09-25T15:52:50Z

<p>Mbaney: </p> <hr /> <div>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!<br /> <br /> In general, we expect that you do not use more than 1-2GB of memory at a time and do not sustain &gt;=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.<br /> <br /> =Examples=<br /> <br /> ==Appropriate submission node uses==<br /> <br /> * Running Slurm job submission commands: &lt;code&gt;srun&lt;/code&gt;, &lt;code&gt;salloc&lt;/code&gt;, &lt;code&gt;sbatch&lt;/code&gt;<br /> * Using as a SSH jump host to connect to other hosts<br /> * Performing basic code editing in editors with minimal extensions, e.g., emacs, nano, vim, neovim without an LSP.<br /> <br /> ==Appropriate submission node uses, with caveats==<br /> <br /> 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.<br /> <br /> * 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.<br /> ** 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.<br /> * 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.<br /> ** Depending on a project's file structure, code compilation can be highly I/O dependent, which can also impact user interactivity.<br /> * Setting up environments with user package managers, e.g., pip, npm, conda/mamba.<br /> ** 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.<br /> * Running lightweight programs to interact with Slurm jobs currently running on the cluster.<br /> <br /> ==Inappropriate submission node uses==<br /> <br /> If tech staff notices processes with the following behavior and node interactivity is affected, &lt;b&gt;we may kill these processes&lt;/b&gt;. If you repeatedly cause issues, further action may be taken on your account.<br /> <br /> * Compiling large projects using all threads on a submission node.<br /> * Running nontrivial computation requiring significant CPU and/or memory resources.<br /> <br /> =Advice for monitoring/reducing CPU/memory utilization=<br /> <br /> Here is some general guidance for tracking your resource utilization on a node, as well as some practices you can follow to slightly reduce CPU usage of certain tasks.<br /> <br /> * `top`<br /> ** By default, `top` sorts by %CPU, but you can sort by %MEM by pressing &quot;M&quot; (Shift + &quot;m&quot;).<br /> ** You can limit it to show only processes from your user by starting it with `-u $USER`<br /> ** VIRT memory usage doesn't mean too much, as oftentimes programs will request way more memory than they actually need, and the kernel may not actually give them this memory until it is actually required. RSS memory is the actual amount of memory used by a process at a given point. If there is no suffix, the reported value is in KB.<br /> * /sys/fs/cgroup/memory/user.slice/user-$UID_NUMBER.slice/memory.usage_in_bytes<br /> ** This is the current combined memory usage of all processes running under your user.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=Nexus/Submission_Node_Policy&diff=13421 2026-09-25T15:52:26Z

<p>Mbaney: </p> <hr /> <div>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 in the future. For the time being, be a good neighbor!<br /> <br /> In general, we expect that you do not use more than 1-2GB of memory at a time and do not sustain &gt;=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.<br /> <br /> =Examples=<br /> <br /> ==Appropriate submission node uses==<br /> <br /> * Running Slurm job submission commands: &lt;code&gt;srun&lt;/code&gt;, &lt;code&gt;salloc&lt;/code&gt;, &lt;code&gt;sbatch&lt;/code&gt;<br /> * Using as a SSH jump host to connect to other hosts<br /> * Performing basic code editing in editors with minimal extensions, e.g., emacs, nano, vim, neovim without an LSP.<br /> <br /> ==Appropriate submission node uses, with caveats==<br /> <br /> 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.<br /> <br /> * 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.<br /> ** 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.<br /> * 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.<br /> ** Depending on a project's file structure, code compilation can be highly I/O dependent, which can also impact user interactivity.<br /> * Setting up environments with user package managers, e.g., pip, npm, conda/mamba.<br /> ** 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.<br /> * Running lightweight programs to interact with Slurm jobs currently running on the cluster.<br /> <br /> ==Inappropriate submission node uses==<br /> <br /> If tech staff notices processes with the following behavior and node interactivity is affected, &lt;b&gt;we may kill these processes&lt;/b&gt;. If you repeatedly cause issues, further action may be taken on your account.<br /> <br /> * Compiling large projects using all threads on a submission node.<br /> * Running nontrivial computation requiring significant CPU and/or memory resources.<br /> <br /> =Advice for monitoring/reducing CPU/memory utilization=<br /> <br /> Here is some general guidance for tracking your resource utilization on a node, as well as some practices you can follow to slightly reduce CPU usage of certain tasks.<br /> <br /> * `top`<br /> ** By default, `top` sorts by %CPU, but you can sort by %MEM by pressing &quot;M&quot; (Shift + &quot;m&quot;).<br /> ** You can limit it to show only processes from your user by starting it with `-u $USER`<br /> ** VIRT memory usage doesn't mean too much, as oftentimes programs will request way more memory than they actually need, and the kernel may not actually give them this memory until it is actually required. RSS memory is the actual amount of memory used by a process at a given point. If there is no suffix, the reported value is in KB.<br /> * /sys/fs/cgroup/memory/user.slice/user-$UID_NUMBER.slice/memory.usage_in_bytes<br /> ** This is the current combined memory usage of all processes running under your user.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=Nexus/Submission_Node_Policy&diff=13420 2026-09-25T15:49:05Z

<p>Mbaney: </p> <hr /> <div>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!<br /> <br /> 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 &gt;=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.<br /> <br /> =Examples=<br /> <br /> ==Appropriate submission node uses==<br /> <br /> * Running Slurm job submission commands: &lt;code&gt;srun&lt;/code&gt;, &lt;code&gt;salloc&lt;/code&gt;, &lt;code&gt;sbatch&lt;/code&gt;<br /> * Using as a SSH jump host to connect to other hosts<br /> * Performing basic code editing in editors with minimal extensions, e.g., emacs, nano, vim, neovim without an LSP.<br /> <br /> ==Appropriate submission node uses, with caveats==<br /> <br /> 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.<br /> <br /> * 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.<br /> ** 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.<br /> * 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.<br /> ** Depending on a project's file structure, code compilation can be highly I/O dependent, which can also impact user interactivity.<br /> * Setting up environments with user package managers, e.g., pip, npm, conda/mamba.<br /> ** 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.<br /> * Running lightweight programs to interact with Slurm jobs currently running on the cluster.<br /> <br /> ==Inappropriate submission node uses==<br /> <br /> If tech staff notices processes with the following behavior and node interactivity is affected, &lt;b&gt;we may kill these processes&lt;/b&gt;. If a user repeatedly causes issues, further action may be taken on their account.<br /> <br /> * Compiling large projects using all threads on a submission node.<br /> * Running nontrivial computation requiring significant CPU and/or memory resources.<br /> <br /> =Advice for monitoring/reducing CPU/memory utilization=<br /> <br /> Here is some general guidance for tracking your resource utilization on a node, as well as some practices you can follow to slightly reduce CPU usage of certain tasks.<br /> <br /> * `top`<br /> ** By default, `top` sorts by %CPU, but you can sort by %MEM by pressing &quot;M&quot; (Shift + &quot;m&quot;).<br /> ** You can limit it to show only processes from your user by starting it with `-u $USER`<br /> ** VIRT memory usage doesn't mean too much, as oftentimes programs will request way more memory than they actually need, and the kernel may not actually give them this memory until it is actually required. RSS memory is the actual amount of memory used by a process at a given point. If there is no suffix, the reported value is in KB.<br /> * /sys/fs/cgroup/memory/user.slice/user-$UID_NUMBER.slice/memory.usage_in_bytes<br /> ** This is the current combined memory usage of all processes running under your user.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=Nexus/Submission_Node_Policy&diff=13419 2026-09-25T15:46:34Z

<p>Mbaney: </p> <hr /> <div>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!<br /> <br /> 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 &gt;=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.<br /> <br /> =Examples=<br /> <br /> ==Appropriate submission node uses==<br /> <br /> * Running Slurm job submission commands: &lt;code&gt;srun&lt;/code&gt;, &lt;code&gt;salloc&lt;/code&gt;, &lt;code&gt;sbatch&lt;/code&gt;<br /> * Using as a SSH jump host to connect to other hosts<br /> * Performing basic code editing in editors with minimal extensions, e.g., emacs, nano, vim, neovim without an LSP.<br /> <br /> ==Appropriate submission node uses, with caveats==<br /> <br /> 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.<br /> <br /> * 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.<br /> ** 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.<br /> * 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.<br /> ** Depending on a project's file structure, code compilation can be highly I/O dependent, which can also impact user interactivity.<br /> * Setting up environments with user package managers, e.g., pip, npm, conda/mamba.<br /> ** 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.<br /> * Running lightweight programs to interact with Slurm jobs currently running on the cluster.<br /> <br /> ==Inappropriate submission node uses==<br /> <br /> If tech staff notices processes with the following behavior and node interactivity is affected, &lt;b&gt;we may kill these processes&lt;/b&gt;. If a user repeatedly causes issues, further action may be taken on their account.<br /> <br /> * Compiling large projects using all threads on a submission node.<br /> * Running nontrivial computation requiring significant CPU and/or memory resources.<br /> <br /> =Advice for monitoring/reducing CPU/memory utilization=<br /> <br /> Here is some general guidance for tracking your resource utilization on a node, as well as some practices you can follow to slightly reduce CPU usage of certain tasks.<br /> <br /> * `top`<br /> ** By default, `top` sorts by %CPU, but you can sort by %MEM by pressing &quot;M&quot; (Shift + &quot;m&quot;).<br /> ** You can limit it to show only processes from your user by starting it with `-u $USER`<br /> ** VIRT memory usage doesn't mean too much, as oftentimes programs will request way more memory than they actually need, and the kernel may not actually give them this memory until it is actually required. RSS memory is the actual amount of memory used by a process at a given point. If there is no suffix, the reported value is in KB.<br /> * /sys/fs/cgroup/memory/user.slice/user-$UID_NUMBER.slice/memory.usage_in_bytes<br /> ** This is the current combined memory usage of all processes running under your user.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=Nexus/Submission_Node_Policy&diff=13418 2026-09-25T15:42:20Z

<p>Mbaney: </p> <hr /> <div>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!<br /> <br /> 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 &gt;=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.<br /> <br /> =Examples=<br /> <br /> ==Appropriate submission node uses==<br /> <br /> * Running Slurm job submission commands: &lt;code&gt;srun&lt;/code&gt;, &lt;code&gt;salloc&lt;/code&gt;, &lt;code&gt;sbatch&lt;/code&gt;<br /> * Using as a SSH jump host to connect to other hosts<br /> * Performing basic code editing in editors with minimal extensions (e.g. emacs, nano, vim, neovim without an LSP).<br /> <br /> ==Appropriate submission node uses, with caveats==<br /> <br /> 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.<br /> <br /> * IDEs can be fine, but keep in mind which extensions you install. Some extensions/behaviors may use more memory/CPU than you realize.<br /> ** We have some [[VS_Code|guidance for VS Code and its forks]].<br /> * 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).<br /> ** Depending on a project's file structure, code compilation can be highly I/O dependent, which can also impact user interactivity.<br /> * Setting up environments with user package managers (e.g. pip, npm, conda/mamba)<br /> ** 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).<br /> * Running lightweight programs to interact with Slurm jobs currently running on the cluster.<br /> <br /> ==Inappropriate submission node uses==<br /> <br /> If tech staff notices processes with the following behavior and node interactivity is affected, &lt;b&gt;we may kill these processes&lt;/b&gt;. If a user repeatedly causes issues, further action may be taken on their account.<br /> <br /> * Compiling large projects using all threads on a submission node.<br /> * Running nontrivial computation requiring significant CPU and/or memory resources.<br /> <br /> =Advice for monitoring/reducing CPU/memory utilization=<br /> <br /> Here is some general guidance for tracking your resource utilization on a node, as well as some practices you can follow to slightly reduce CPU usage of certain tasks.<br /> <br /> * `top`<br /> ** By default, `top` sorts by %CPU, but you can sort by %MEM by pressing &quot;M&quot; (Shift + &quot;m&quot;).<br /> ** You can limit it to show only processes from your user by starting it with `-u $USER`<br /> ** VIRT memory usage doesn't mean too much, as oftentimes programs will request way more memory than they actually need, and the kernel may not actually give them this memory until it is actually required. RSS memory is the actual amount of memory used by a process at a given point. If there is no suffix, the reported value is in KB.<br /> * /sys/fs/cgroup/memory/user.slice/user-$UID_NUMBER.slice/memory.usage_in_bytes<br /> ** This is the current combined memory usage of all processes running under your user.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=VS_Code&diff=13417 2026-09-25T14:36:03Z

<p>Mbaney: /* Running VS Code on a Compute Node */</p> <hr /> <div>[https://code.visualstudio.com/ Visual Studio (VS) Code] is a multi-platform source-code editor developed by Microsoft. It can be used with a variety of programming languages and can have its base functionality extended through extensions available via its [https://marketplace.visualstudio.com/vscode marketplace]. The base editor itself is free, but some extensions may require paid subscriptions.<br /> <br /> There are also forks/open source alternatives of VS Code, such as [https://www.cursor.com Cursor] or [https://vscodium.com/ VSCodium]. The same general principals below apply to these editors as well.<br /> <br /> ==Cluster Usage==<br /> 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.<br /> <br /> 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].<br /> <br /> ===Best Practices===<br /> Because of the multi-tenant nature of our submission nodes, using the Remote - SSH extension to connect to a VS Code Server running on a submission node can have adverse affects on other users simultaneously using the submission nodes if not properly managed. The following is a list of &quot;best practices&quot; that we ask you please follow to minimize the chance of impacting others on submission nodes. We have compiled the list through observation as well as through discussion with users.<br /> <br /> ====Use only as a code editor====<br /> VS Code can perform many common file management operations, such as moving, copying, or deleting files or directories. However, the overhead of providing progress updates / status messages through VS Code's UI can cause load spikes that result in other system-level and user processes on the submission node slowing down. This is especially the case if operating on thousands to millions of small image or video files. In extreme cases, it can seem as though the submission node is wholly unresponsive.<br /> <br /> The best way to combat this is to use VS Code as just a code editor as strictly as you can (meaning creating new and/or editing existing source code files only). Use standard command-line programs such as &lt;code&gt;mv&lt;/code&gt;/&lt;code&gt;cp&lt;/code&gt;/&lt;code&gt;rm&lt;/code&gt; in VS Code's terminal window or a separate application's terminal window for local file management instead, or use the techniques advertised [[LocalDataTransfer | here]] for larger data transfers between nodes.<br /> <br /> ====Do not open large files====<br /> Files that you open in VS Code's text editor on a remote machine through the Remote - SSH extension are loaded entirely into RAM on the remote machine. Because of the persistence of VS Code Server processes, opening several unique files may result in them all remaining in RAM for extended periods of time even if you no longer have tabs open for them in the Tab Bar.<br /> <br /> As such, please refrain from opening large files (more than a few MB) in VS Code itself on submission nodes. Use a lighter-weight command-line based text editor such as [https://www.vim.org vim] or otherwise in VS Code's terminal window or a separate application's terminal window for local file editing instead.<br /> <br /> If you absolutely need to open one or more large files for a very brief period of time on a submission node, please clean up your server session on that node (see below section) as soon as possible when done.<br /> <br /> ====Ripgrep====<br /> 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 &quot;rg --files&quot;, 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.<br /> <br /> # '''Keep data separate from code where possible'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search&quot;.<br /> # '''Limit maximum number of threads for searches'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search-&gt;Ripgrep: Max Threads&quot; in order to limit the performance impact.<br /> <br /> ====Clean up when done====<br /> 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.<br /> <br /> # '''Shortening the Remote-SSH Reconnection Grace Time'''<br /> #: You can configure the Remote-SSH extension to reduce this time to something reasonable (e.g. 5 minutes).<br /> #: This can be done by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching &quot;Remote-SSH: Settings&quot;.<br /> #: [[File:VSCode-remotesshsettings.jpg|alt=Under the Command Palette menu, &quot;Remote-SSH: Settings&quot; is searched.]]<br /> #: This will open a dialog box with settings for the Remote-SSH extension. From here, you can scroll down or search for &quot;Remote.SSH: Reconnection Grace Time&quot; and configure this to something reasonable.<br /> #: [[File:VSCode-reconnectiongracetime.jpg|alt=In the &quot;Settings&quot; dialog box, &quot;Remote.SSH: Reconnection Grace Time&quot; is overridden to 300 seconds.]]<br /> # '''Manually killing a remote VS Code server'''<br /> #: 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 &quot;Kill VS Code Server on Host...&quot;.<br /> #: [[File:VSCode-killremote1.png|alt=Under the Command Palette menu, &quot;Kill VS Code Server on Host...&quot; is searched.]]<br /> #: Select the submission node you were using and click on it.<br /> #: [[File:VSCode-killremote2.png|alt='nexus' is searched and a 2 submission nodes pop up as matching searches.]]<br /> #: Wait a few seconds and you should get a message confirming the command went through.<br /> #: [[File:VSCode-killremote3.png|alt=Pop-up confirming the kill command went through.]]<br /> #: The next time you connect to the same submission node, you will have a fresh VS Code session on it.<br /> <br /> ===Running VS Code on a Compute Node===<br /> 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.<br /> <br /> # SSH to your submission node.<br /> # Open a [[Tmux]] session for your salloc command. salloc will only hold your allocation if you don't close your shell, so tmux is a convenient way to keep a persistent shell open on the submission node.<br /> # In your tmux session on the submission node, use &lt;code&gt;salloc&lt;/code&gt; to request an allocation on a compute node. Once allocated, it will print the hostname of the compute node you were allocated.<br /> #* Example: &lt;code&gt;salloc --cpus-per-task=2 --mem=4G&lt;/code&gt;<br /> #* You can adjust the CPUs, memory, and time limit as needed.<br /> #* Without any other arguments, this allocation will be under the 'nexus' account on the '[[Nexus/Tron | tron]]' partition, subject to the 'default' QoS resource limits. If you need resources beyond what the default QoS allows, you can adjust the account/partition/QoS assigned to the allocation as you can with any other job.<br /> #*: [[File:Salloc example.png|thumb|400px|none|Example of output from running salloc.]]<br /> # On your local machine, use the Remote-SSH plugin on VS Code to connect directly to the compute node.<br /> #: [[File:Add remote.png|thumb|400px|none|If the compute node is not defined, press the &quot;+&quot; 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.]]<br /> # Once connected, begin using VS Code on the compute node however you would like - your allocation is constrained to the amount of CPUs and memory requested, so it will not affect other users' jobs / allocations running on the node. If you find that your processes are being killed within your allocation due to running out of memory, try requesting more memory for your next allocation.<br /> <br /> ==Common Issues==<br /> If you are having trouble [[SSH]]'ing to a submission node with VS Code, check if your home directory is full.<br /> <br /> # Connect to one of your Nexus submission nodes via [[SSH]] '''not''' using VS Code.<br /> # Navigate to your home directory. &lt;pre&gt;cd ~&lt;/pre&gt;<br /> # Check if it is full. &lt;pre&gt;df -h .&lt;/pre&gt;<br /> # If it is full (Avail 0), delete some files to free up at least ~100MB of space. &lt;pre&gt;Filesystem Size Used Avail Use% Mounted on&amp;#10;data.isilon.umiacs.umd.edu:/ifs/umiacs/homes 30G 30G 0 100% /fs/nfshomes&lt;/pre&gt;<br /> # Try connecting with VS Code again.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=VS_Code&diff=13416 2026-09-25T14:31:51Z

<p>Mbaney: /* Running VS Code on a Compute Node */</p> <hr /> <div>[https://code.visualstudio.com/ Visual Studio (VS) Code] is a multi-platform source-code editor developed by Microsoft. It can be used with a variety of programming languages and can have its base functionality extended through extensions available via its [https://marketplace.visualstudio.com/vscode marketplace]. The base editor itself is free, but some extensions may require paid subscriptions.<br /> <br /> There are also forks/open source alternatives of VS Code, such as [https://www.cursor.com Cursor] or [https://vscodium.com/ VSCodium]. The same general principals below apply to these editors as well.<br /> <br /> ==Cluster Usage==<br /> 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.<br /> <br /> 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].<br /> <br /> ===Best Practices===<br /> Because of the multi-tenant nature of our submission nodes, using the Remote - SSH extension to connect to a VS Code Server running on a submission node can have adverse affects on other users simultaneously using the submission nodes if not properly managed. The following is a list of &quot;best practices&quot; that we ask you please follow to minimize the chance of impacting others on submission nodes. We have compiled the list through observation as well as through discussion with users.<br /> <br /> ====Use only as a code editor====<br /> VS Code can perform many common file management operations, such as moving, copying, or deleting files or directories. However, the overhead of providing progress updates / status messages through VS Code's UI can cause load spikes that result in other system-level and user processes on the submission node slowing down. This is especially the case if operating on thousands to millions of small image or video files. In extreme cases, it can seem as though the submission node is wholly unresponsive.<br /> <br /> The best way to combat this is to use VS Code as just a code editor as strictly as you can (meaning creating new and/or editing existing source code files only). Use standard command-line programs such as &lt;code&gt;mv&lt;/code&gt;/&lt;code&gt;cp&lt;/code&gt;/&lt;code&gt;rm&lt;/code&gt; in VS Code's terminal window or a separate application's terminal window for local file management instead, or use the techniques advertised [[LocalDataTransfer | here]] for larger data transfers between nodes.<br /> <br /> ====Do not open large files====<br /> Files that you open in VS Code's text editor on a remote machine through the Remote - SSH extension are loaded entirely into RAM on the remote machine. Because of the persistence of VS Code Server processes, opening several unique files may result in them all remaining in RAM for extended periods of time even if you no longer have tabs open for them in the Tab Bar.<br /> <br /> As such, please refrain from opening large files (more than a few MB) in VS Code itself on submission nodes. Use a lighter-weight command-line based text editor such as [https://www.vim.org vim] or otherwise in VS Code's terminal window or a separate application's terminal window for local file editing instead.<br /> <br /> If you absolutely need to open one or more large files for a very brief period of time on a submission node, please clean up your server session on that node (see below section) as soon as possible when done.<br /> <br /> ====Ripgrep====<br /> 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 &quot;rg --files&quot;, 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.<br /> <br /> # '''Keep data separate from code where possible'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search&quot;.<br /> # '''Limit maximum number of threads for searches'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search-&gt;Ripgrep: Max Threads&quot; in order to limit the performance impact.<br /> <br /> ====Clean up when done====<br /> 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.<br /> <br /> # '''Shortening the Remote-SSH Reconnection Grace Time'''<br /> #: You can configure the Remote-SSH extension to reduce this time to something reasonable (e.g. 5 minutes).<br /> #: This can be done by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching &quot;Remote-SSH: Settings&quot;.<br /> #: [[File:VSCode-remotesshsettings.jpg|alt=Under the Command Palette menu, &quot;Remote-SSH: Settings&quot; is searched.]]<br /> #: This will open a dialog box with settings for the Remote-SSH extension. From here, you can scroll down or search for &quot;Remote.SSH: Reconnection Grace Time&quot; and configure this to something reasonable.<br /> #: [[File:VSCode-reconnectiongracetime.jpg|alt=In the &quot;Settings&quot; dialog box, &quot;Remote.SSH: Reconnection Grace Time&quot; is overridden to 300 seconds.]]<br /> # '''Manually killing a remote VS Code server'''<br /> #: 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 &quot;Kill VS Code Server on Host...&quot;.<br /> #: [[File:VSCode-killremote1.png|alt=Under the Command Palette menu, &quot;Kill VS Code Server on Host...&quot; is searched.]]<br /> #: Select the submission node you were using and click on it.<br /> #: [[File:VSCode-killremote2.png|alt='nexus' is searched and a 2 submission nodes pop up as matching searches.]]<br /> #: Wait a few seconds and you should get a message confirming the command went through.<br /> #: [[File:VSCode-killremote3.png|alt=Pop-up confirming the kill command went through.]]<br /> #: The next time you connect to the same submission node, you will have a fresh VS Code session on it.<br /> <br /> ===Running VS Code on a Compute Node===<br /> 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.<br /> <br /> # SSH to your submission node.<br /> # Open a [[Tmux]] session for your salloc command. salloc will only hold your allocation if you don't close your shell, so tmux is a convenient way to keep a persistent shell open on the submission node.<br /> # In your tmux session on the submission node, use &lt;code&gt;salloc&lt;/code&gt; to request an allocation on a compute node. Once allocated, it will print the hostname of the compute node you were allocated.<br /> #* Example: &lt;code&gt;salloc --cpus-per-task=2 --mem=4G&lt;/code&gt;<br /> #* You can adjust the CPUs, memory, and time limit as needed.<br /> #* Without any other arguments, this allocation will be on the [[Nexus/Tron | tron]] partition, subject to the &lt;code&gt;default&lt;/code&gt; QoS resource limits. If you need resources beyond what the default QoS allows, you can adjust the account/partition/QoS assigned to the allocation as you can with any other job.<br /> #*: [[File:Salloc example.png|thumb|400px|none|Example of output from running salloc.]]<br /> # On your local machine, use the Remote-SSH plugin on VS Code to connect directly to the compute node.<br /> #: [[File:Add remote.png|thumb|400px|none|If the compute node is not defined, press the &quot;+&quot; 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.]]<br /> # Once connected, begin using VS Code on the compute node however you would like - your allocation is constrained to the amount of CPUs and memory requested, so it will not affect other users' jobs / allocations running on the node. If you find that your processes are being killed within your allocation due to running out of memory, try requesting more memory for your next allocation.<br /> <br /> ==Common Issues==<br /> If you are having trouble [[SSH]]'ing to a submission node with VS Code, check if your home directory is full.<br /> <br /> # Connect to one of your Nexus submission nodes via [[SSH]] '''not''' using VS Code.<br /> # Navigate to your home directory. &lt;pre&gt;cd ~&lt;/pre&gt;<br /> # Check if it is full. &lt;pre&gt;df -h .&lt;/pre&gt;<br /> # If it is full (Avail 0), delete some files to free up at least ~100MB of space. &lt;pre&gt;Filesystem Size Used Avail Use% Mounted on&amp;#10;data.isilon.umiacs.umd.edu:/ifs/umiacs/homes 30G 30G 0 100% /fs/nfshomes&lt;/pre&gt;<br /> # Try connecting with VS Code again.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=VS_Code&diff=13415 2026-09-24T18:22:03Z

<p>Mbaney: /* Running VS Code on a Compute Node */</p> <hr /> <div>[https://code.visualstudio.com/ Visual Studio (VS) Code] is a multi-platform source-code editor developed by Microsoft. It can be used with a variety of programming languages and can have its base functionality extended through extensions available via its [https://marketplace.visualstudio.com/vscode marketplace]. The base editor itself is free, but some extensions may require paid subscriptions.<br /> <br /> There are also forks/open source alternatives of VS Code, such as [https://www.cursor.com Cursor] or [https://vscodium.com/ VSCodium]. The same general principals below apply to these editors as well.<br /> <br /> ==Cluster Usage==<br /> 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.<br /> <br /> 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].<br /> <br /> ===Best Practices===<br /> Because of the multi-tenant nature of our submission nodes, using the Remote - SSH extension to connect to a VS Code Server running on a submission node can have adverse affects on other users simultaneously using the submission nodes if not properly managed. The following is a list of &quot;best practices&quot; that we ask you please follow to minimize the chance of impacting others on submission nodes. We have compiled the list through observation as well as through discussion with users.<br /> <br /> ====Use only as a code editor====<br /> VS Code can perform many common file management operations, such as moving, copying, or deleting files or directories. However, the overhead of providing progress updates / status messages through VS Code's UI can cause load spikes that result in other system-level and user processes on the submission node slowing down. This is especially the case if operating on thousands to millions of small image or video files. In extreme cases, it can seem as though the submission node is wholly unresponsive.<br /> <br /> The best way to combat this is to use VS Code as just a code editor as strictly as you can (meaning creating new and/or editing existing source code files only). Use standard command-line programs such as &lt;code&gt;mv&lt;/code&gt;/&lt;code&gt;cp&lt;/code&gt;/&lt;code&gt;rm&lt;/code&gt; in VS Code's terminal window or a separate application's terminal window for local file management instead, or use the techniques advertised [[LocalDataTransfer | here]] for larger data transfers between nodes.<br /> <br /> ====Do not open large files====<br /> Files that you open in VS Code's text editor on a remote machine through the Remote - SSH extension are loaded entirely into RAM on the remote machine. Because of the persistence of VS Code Server processes, opening several unique files may result in them all remaining in RAM for extended periods of time even if you no longer have tabs open for them in the Tab Bar.<br /> <br /> As such, please refrain from opening large files (more than a few MB) in VS Code itself on submission nodes. Use a lighter-weight command-line based text editor such as [https://www.vim.org vim] or otherwise in VS Code's terminal window or a separate application's terminal window for local file editing instead.<br /> <br /> If you absolutely need to open one or more large files for a very brief period of time on a submission node, please clean up your server session on that node (see below section) as soon as possible when done.<br /> <br /> ====Ripgrep====<br /> 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 &quot;rg --files&quot;, 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.<br /> <br /> # '''Keep data separate from code where possible'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search&quot;.<br /> # '''Limit maximum number of threads for searches'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search-&gt;Ripgrep: Max Threads&quot; in order to limit the performance impact.<br /> <br /> ====Clean up when done====<br /> 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.<br /> <br /> # '''Shortening the Remote-SSH Reconnection Grace Time'''<br /> #: You can configure the Remote-SSH extension to reduce this time to something reasonable (e.g. 5 minutes).<br /> #: This can be done by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching &quot;Remote-SSH: Settings&quot;.<br /> #: [[File:VSCode-remotesshsettings.jpg|alt=Under the Command Palette menu, &quot;Remote-SSH: Settings&quot; is searched.]]<br /> #: This will open a dialog box with settings for the Remote-SSH extension. From here, you can scroll down or search for &quot;Remote.SSH: Reconnection Grace Time&quot; and configure this to something reasonable.<br /> #: [[File:VSCode-reconnectiongracetime.jpg|alt=In the &quot;Settings&quot; dialog box, &quot;Remote.SSH: Reconnection Grace Time&quot; is overridden to 300 seconds.]]<br /> # '''Manually killing a remote VS Code server'''<br /> #: 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 &quot;Kill VS Code Server on Host...&quot;.<br /> #: [[File:VSCode-killremote1.png|alt=Under the Command Palette menu, &quot;Kill VS Code Server on Host...&quot; is searched.]]<br /> #: Select the submission node you were using and click on it.<br /> #: [[File:VSCode-killremote2.png|alt='nexus' is searched and a 2 submission nodes pop up as matching searches.]]<br /> #: Wait a few seconds and you should get a message confirming the command went through.<br /> #: [[File:VSCode-killremote3.png|alt=Pop-up confirming the kill command went through.]]<br /> #: The next time you connect to the same submission node, you will have a fresh VS Code session on it.<br /> <br /> ===Running VS Code on a Compute Node===<br /> 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.<br /> <br /> # SSH to your submission node.<br /> # Open a [[Tmux]] session for your salloc command. salloc will only hold your allocation if you don't close your shell, so tmux is a convenient way to keep a persistent shell open on the submission node.<br /> # In your tmux session on the submission node, use &lt;code&gt;salloc&lt;/code&gt; to request an allocation on a compute node. Once allocated, it will print the hostname of the compute node you were allocated.<br /> #* Example: &lt;code&gt;salloc --mem=4G --cpus-per-task=2&lt;/code&gt;<br /> #* You can adjust the memory, CPUs, and time limit as needed.<br /> #* Without any other arguments, this allocation will be on the [[Nexus/Tron | tron]] partition, subject to the &lt;code&gt;default&lt;/code&gt; QoS resource limits. If you need resources beyond what the default QoS allows, you can adjust the account/partition/QoS assigned to the allocation as you can with any other job.<br /> #*: [[File:Salloc example.png|thumb|400px|none|Example of output from running salloc.]]<br /> # On your local machine, use the Remote-SSH plugin on VS Code to connect directly to the compute node.<br /> #: [[File:Add remote.png|thumb|400px|none|If the compute node is not defined, press the &quot;+&quot; 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.]]<br /> # Once connected, begin using VS Code on the compute node however you would like - your allocation is constrained to the amount of memory and CPUs requested, so it will not affect other users' jobs / allocations running on the node. If you find that your processes are being killed within your allocation due to running out of memory, try requesting more memory for your next allocation.<br /> <br /> ==Common Issues==<br /> If you are having trouble [[SSH]]'ing to a submission node with VS Code, check if your home directory is full.<br /> <br /> # Connect to one of your Nexus submission nodes via [[SSH]] '''not''' using VS Code.<br /> # Navigate to your home directory. &lt;pre&gt;cd ~&lt;/pre&gt;<br /> # Check if it is full. &lt;pre&gt;df -h .&lt;/pre&gt;<br /> # If it is full (Avail 0), delete some files to free up at least ~100MB of space. &lt;pre&gt;Filesystem Size Used Avail Use% Mounted on&amp;#10;data.isilon.umiacs.umd.edu:/ifs/umiacs/homes 30G 30G 0 100% /fs/nfshomes&lt;/pre&gt;<br /> # Try connecting with VS Code again.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=VS_Code&diff=13414 2026-09-24T18:13:14Z

<p>Mbaney: /* Running VS Code on a Compute Node */</p> <hr /> <div>[https://code.visualstudio.com/ Visual Studio (VS) Code] is a multi-platform source-code editor developed by Microsoft. It can be used with a variety of programming languages and can have its base functionality extended through extensions available via its [https://marketplace.visualstudio.com/vscode marketplace]. The base editor itself is free, but some extensions may require paid subscriptions.<br /> <br /> There are also forks/open source alternatives of VS Code, such as [https://www.cursor.com Cursor] or [https://vscodium.com/ VSCodium]. The same general principals below apply to these editors as well.<br /> <br /> ==Cluster Usage==<br /> 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.<br /> <br /> 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].<br /> <br /> ===Best Practices===<br /> Because of the multi-tenant nature of our submission nodes, using the Remote - SSH extension to connect to a VS Code Server running on a submission node can have adverse affects on other users simultaneously using the submission nodes if not properly managed. The following is a list of &quot;best practices&quot; that we ask you please follow to minimize the chance of impacting others on submission nodes. We have compiled the list through observation as well as through discussion with users.<br /> <br /> ====Use only as a code editor====<br /> VS Code can perform many common file management operations, such as moving, copying, or deleting files or directories. However, the overhead of providing progress updates / status messages through VS Code's UI can cause load spikes that result in other system-level and user processes on the submission node slowing down. This is especially the case if operating on thousands to millions of small image or video files. In extreme cases, it can seem as though the submission node is wholly unresponsive.<br /> <br /> The best way to combat this is to use VS Code as just a code editor as strictly as you can (meaning creating new and/or editing existing source code files only). Use standard command-line programs such as &lt;code&gt;mv&lt;/code&gt;/&lt;code&gt;cp&lt;/code&gt;/&lt;code&gt;rm&lt;/code&gt; in VS Code's terminal window or a separate application's terminal window for local file management instead, or use the techniques advertised [[LocalDataTransfer | here]] for larger data transfers between nodes.<br /> <br /> ====Do not open large files====<br /> Files that you open in VS Code's text editor on a remote machine through the Remote - SSH extension are loaded entirely into RAM on the remote machine. Because of the persistence of VS Code Server processes, opening several unique files may result in them all remaining in RAM for extended periods of time even if you no longer have tabs open for them in the Tab Bar.<br /> <br /> As such, please refrain from opening large files (more than a few MB) in VS Code itself on submission nodes. Use a lighter-weight command-line based text editor such as [https://www.vim.org vim] or otherwise in VS Code's terminal window or a separate application's terminal window for local file editing instead.<br /> <br /> If you absolutely need to open one or more large files for a very brief period of time on a submission node, please clean up your server session on that node (see below section) as soon as possible when done.<br /> <br /> ====Ripgrep====<br /> 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 &quot;rg --files&quot;, 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.<br /> <br /> # '''Keep data separate from code where possible'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search&quot;.<br /> # '''Limit maximum number of threads for searches'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search-&gt;Ripgrep: Max Threads&quot; in order to limit the performance impact.<br /> <br /> ====Clean up when done====<br /> 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.<br /> <br /> # '''Shortening the Remote-SSH Reconnection Grace Time'''<br /> #: You can configure the Remote-SSH extension to reduce this time to something reasonable (e.g. 5 minutes).<br /> #: This can be done by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching &quot;Remote-SSH: Settings&quot;.<br /> #: [[File:VSCode-remotesshsettings.jpg|alt=Under the Command Palette menu, &quot;Remote-SSH: Settings&quot; is searched.]]<br /> #: This will open a dialog box with settings for the Remote-SSH extension. From here, you can scroll down or search for &quot;Remote.SSH: Reconnection Grace Time&quot; and configure this to something reasonable.<br /> #: [[File:VSCode-reconnectiongracetime.jpg|alt=In the &quot;Settings&quot; dialog box, &quot;Remote.SSH: Reconnection Grace Time&quot; is overridden to 300 seconds.]]<br /> # '''Manually killing a remote VS Code server'''<br /> #: 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 &quot;Kill VS Code Server on Host...&quot;.<br /> #: [[File:VSCode-killremote1.png|alt=Under the Command Palette menu, &quot;Kill VS Code Server on Host...&quot; is searched.]]<br /> #: Select the submission node you were using and click on it.<br /> #: [[File:VSCode-killremote2.png|alt='nexus' is searched and a 2 submission nodes pop up as matching searches.]]<br /> #: Wait a few seconds and you should get a message confirming the command went through.<br /> #: [[File:VSCode-killremote3.png|alt=Pop-up confirming the kill command went through.]]<br /> #: The next time you connect to the same submission node, you will have a fresh VS Code session on it.<br /> <br /> ===Running VS Code on a Compute Node===<br /> 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.<br /> <br /> # SSH to your submission node.<br /> # Open a [[Tmux]] session for your salloc command. salloc will only hold your allocation if you don't close your shell, so tmux is a convenient way to keep a persistent shell open on the submission node.<br /> # In your tmux session on the submission node, use &lt;code&gt;salloc&lt;/code&gt; to request an allocation on a compute node. Once allocated, it will print hostname of the compute node which you were allocated.<br /> #* Example: &lt;code&gt;salloc --mem=4G --cpus-per-task=2&lt;/code&gt;<br /> #* You can adjust the memory, CPUs, and time limit as needed.<br /> #* Without any other arguments, this allocation will be on the [[Nexus/Tron | tron]] partition, subject to the &lt;code&gt;default&lt;/code&gt; QoS resource limits. If you need resources beyond what the default QoS allows, you can adjust the account/partition/QoS assigned to the allocation as you can with any other job.<br /> #*: [[File:Salloc example.png|thumb|400px|none|Example of output from running salloc.]]<br /> # On your local machine, use the Remote-SSH plugin on VS Code to connect directly to the compute node.<br /> #: [[File:Add remote.png|thumb|400px|none|If the compute node is not defined, press the &quot;+&quot; 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.]]<br /> # Once connected, begin using VS Code on the compute node however you would like - your allocation is constrained to the amount of memory and CPUs requested, so it will not affect other users' jobs / allocations running on the node. If you find that your processes are being killed within your allocation due to running out of memory, try requesting more memory for your next allocation.<br /> <br /> ==Common Issues==<br /> If you are having trouble [[SSH]]'ing to a submission node with VS Code, check if your home directory is full.<br /> <br /> # Connect to one of your Nexus submission nodes via [[SSH]] '''not''' using VS Code.<br /> # Navigate to your home directory. &lt;pre&gt;cd ~&lt;/pre&gt;<br /> # Check if it is full. &lt;pre&gt;df -h .&lt;/pre&gt;<br /> # If it is full (Avail 0), delete some files to free up at least ~100MB of space. &lt;pre&gt;Filesystem Size Used Avail Use% Mounted on&amp;#10;data.isilon.umiacs.umd.edu:/ifs/umiacs/homes 30G 30G 0 100% /fs/nfshomes&lt;/pre&gt;<br /> # Try connecting with VS Code again.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=VS_Code&diff=13413 2026-09-24T17:46:48Z

<p>Mbaney: /* Running VS Code on a Compute Node */</p> <hr /> <div>[https://code.visualstudio.com/ Visual Studio (VS) Code] is a multi-platform source-code editor developed by Microsoft. It can be used with a variety of programming languages and can have its base functionality extended through extensions available via its [https://marketplace.visualstudio.com/vscode marketplace]. The base editor itself is free, but some extensions may require paid subscriptions.<br /> <br /> There are also forks/open source alternatives of VS Code, such as [https://www.cursor.com Cursor] or [https://vscodium.com/ VSCodium]. The same general principals below apply to these editors as well.<br /> <br /> ==Cluster Usage==<br /> 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.<br /> <br /> 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].<br /> <br /> ===Best Practices===<br /> Because of the multi-tenant nature of our submission nodes, using the Remote - SSH extension to connect to a VS Code Server running on a submission node can have adverse affects on other users simultaneously using the submission nodes if not properly managed. The following is a list of &quot;best practices&quot; that we ask you please follow to minimize the chance of impacting others on submission nodes. We have compiled the list through observation as well as through discussion with users.<br /> <br /> ====Use only as a code editor====<br /> VS Code can perform many common file management operations, such as moving, copying, or deleting files or directories. However, the overhead of providing progress updates / status messages through VS Code's UI can cause load spikes that result in other system-level and user processes on the submission node slowing down. This is especially the case if operating on thousands to millions of small image or video files. In extreme cases, it can seem as though the submission node is wholly unresponsive.<br /> <br /> The best way to combat this is to use VS Code as just a code editor as strictly as you can (meaning creating new and/or editing existing source code files only). Use standard command-line programs such as &lt;code&gt;mv&lt;/code&gt;/&lt;code&gt;cp&lt;/code&gt;/&lt;code&gt;rm&lt;/code&gt; in VS Code's terminal window or a separate application's terminal window for local file management instead, or use the techniques advertised [[LocalDataTransfer | here]] for larger data transfers between nodes.<br /> <br /> ====Do not open large files====<br /> Files that you open in VS Code's text editor on a remote machine through the Remote - SSH extension are loaded entirely into RAM on the remote machine. Because of the persistence of VS Code Server processes, opening several unique files may result in them all remaining in RAM for extended periods of time even if you no longer have tabs open for them in the Tab Bar.<br /> <br /> As such, please refrain from opening large files (more than a few MB) in VS Code itself on submission nodes. Use a lighter-weight command-line based text editor such as [https://www.vim.org vim] or otherwise in VS Code's terminal window or a separate application's terminal window for local file editing instead.<br /> <br /> If you absolutely need to open one or more large files for a very brief period of time on a submission node, please clean up your server session on that node (see below section) as soon as possible when done.<br /> <br /> ====Ripgrep====<br /> 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 &quot;rg --files&quot;, 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.<br /> <br /> # '''Keep data separate from code where possible'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search&quot;.<br /> # '''Limit maximum number of threads for searches'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search-&gt;Ripgrep: Max Threads&quot; in order to limit the performance impact.<br /> <br /> ====Clean up when done====<br /> 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.<br /> <br /> # '''Shortening the Remote-SSH Reconnection Grace Time'''<br /> #: You can configure the Remote-SSH extension to reduce this time to something reasonable (e.g. 5 minutes).<br /> #: This can be done by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching &quot;Remote-SSH: Settings&quot;.<br /> #: [[File:VSCode-remotesshsettings.jpg|alt=Under the Command Palette menu, &quot;Remote-SSH: Settings&quot; is searched.]]<br /> #: This will open a dialog box with settings for the Remote-SSH extension. From here, you can scroll down or search for &quot;Remote.SSH: Reconnection Grace Time&quot; and configure this to something reasonable.<br /> #: [[File:VSCode-reconnectiongracetime.jpg|alt=In the &quot;Settings&quot; dialog box, &quot;Remote.SSH: Reconnection Grace Time&quot; is overridden to 300 seconds.]]<br /> # '''Manually killing a remote VS Code server'''<br /> #: 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 &quot;Kill VS Code Server on Host...&quot;.<br /> #: [[File:VSCode-killremote1.png|alt=Under the Command Palette menu, &quot;Kill VS Code Server on Host...&quot; is searched.]]<br /> #: Select the submission node you were using and click on it.<br /> #: [[File:VSCode-killremote2.png|alt='nexus' is searched and a 2 submission nodes pop up as matching searches.]]<br /> #: Wait a few seconds and you should get a message confirming the command went through.<br /> #: [[File:VSCode-killremote3.png|alt=Pop-up confirming the kill command went through.]]<br /> #: The next time you connect to the same submission node, you will have a fresh VS Code session on it.<br /> <br /> ===Running VS Code on a Compute Node===<br /> 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.<br /> <br /> # SSH to your submission node.<br /> # Open a [[Tmux]] session for your salloc command. salloc will only hold your allocation if you don't close your shell, so tmux is a convenient way to keep a persistent shell open on the submission node.<br /> # In your tmux session on the submission node, use &lt;code&gt;salloc&lt;/code&gt; to request an allocation on a compute node. Once allocated, it will print hostname of the compute node which you were allocated.<br /> #* Example: &lt;code&gt;salloc --mem=4G --cpus-per-task=2&lt;/code&gt;<br /> #* You can adjust the memory, CPUs, and time limit as needed.<br /> #* Without any other arguments, this allocation will be on the [[Nexus/Tron | tron]] partition, subject to the &lt;code&gt;default&lt;/code&gt; QoS resource limits. If you need resources beyond what the default QoS allows, you can adjust the account/partition/QoS assigned to the allocation as you can with any other job.<br /> #*: [[File:Salloc example.png|thumb|400px|none|Example of output from running salloc.]]<br /> # On your local machine, use the Remote-SSH plugin on VS Code to connect directly to the compute node.<br /> #: [[File:Add remote.png|thumb|400px|none|If the compute node is not defined, press the &quot;+&quot; 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.]]<br /> <br /> ==Common Issues==<br /> If you are having trouble [[SSH]]'ing to a submission node with VS Code, check if your home directory is full.<br /> <br /> # Connect to one of your Nexus submission nodes via [[SSH]] '''not''' using VS Code.<br /> # Navigate to your home directory. &lt;pre&gt;cd ~&lt;/pre&gt;<br /> # Check if it is full. &lt;pre&gt;df -h .&lt;/pre&gt;<br /> # If it is full (Avail 0), delete some files to free up at least ~100MB of space. &lt;pre&gt;Filesystem Size Used Avail Use% Mounted on&amp;#10;data.isilon.umiacs.umd.edu:/ifs/umiacs/homes 30G 30G 0 100% /fs/nfshomes&lt;/pre&gt;<br /> # Try connecting with VS Code again.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=VS_Code&diff=13412 2026-09-24T17:45:41Z

<p>Mbaney: </p> <hr /> <div>[https://code.visualstudio.com/ Visual Studio (VS) Code] is a multi-platform source-code editor developed by Microsoft. It can be used with a variety of programming languages and can have its base functionality extended through extensions available via its [https://marketplace.visualstudio.com/vscode marketplace]. The base editor itself is free, but some extensions may require paid subscriptions.<br /> <br /> There are also forks/open source alternatives of VS Code, such as [https://www.cursor.com Cursor] or [https://vscodium.com/ VSCodium]. The same general principals below apply to these editors as well.<br /> <br /> ==Cluster Usage==<br /> 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.<br /> <br /> 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].<br /> <br /> ===Best Practices===<br /> Because of the multi-tenant nature of our submission nodes, using the Remote - SSH extension to connect to a VS Code Server running on a submission node can have adverse affects on other users simultaneously using the submission nodes if not properly managed. The following is a list of &quot;best practices&quot; that we ask you please follow to minimize the chance of impacting others on submission nodes. We have compiled the list through observation as well as through discussion with users.<br /> <br /> ====Use only as a code editor====<br /> VS Code can perform many common file management operations, such as moving, copying, or deleting files or directories. However, the overhead of providing progress updates / status messages through VS Code's UI can cause load spikes that result in other system-level and user processes on the submission node slowing down. This is especially the case if operating on thousands to millions of small image or video files. In extreme cases, it can seem as though the submission node is wholly unresponsive.<br /> <br /> The best way to combat this is to use VS Code as just a code editor as strictly as you can (meaning creating new and/or editing existing source code files only). Use standard command-line programs such as &lt;code&gt;mv&lt;/code&gt;/&lt;code&gt;cp&lt;/code&gt;/&lt;code&gt;rm&lt;/code&gt; in VS Code's terminal window or a separate application's terminal window for local file management instead, or use the techniques advertised [[LocalDataTransfer | here]] for larger data transfers between nodes.<br /> <br /> ====Do not open large files====<br /> Files that you open in VS Code's text editor on a remote machine through the Remote - SSH extension are loaded entirely into RAM on the remote machine. Because of the persistence of VS Code Server processes, opening several unique files may result in them all remaining in RAM for extended periods of time even if you no longer have tabs open for them in the Tab Bar.<br /> <br /> As such, please refrain from opening large files (more than a few MB) in VS Code itself on submission nodes. Use a lighter-weight command-line based text editor such as [https://www.vim.org vim] or otherwise in VS Code's terminal window or a separate application's terminal window for local file editing instead.<br /> <br /> If you absolutely need to open one or more large files for a very brief period of time on a submission node, please clean up your server session on that node (see below section) as soon as possible when done.<br /> <br /> ====Ripgrep====<br /> 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 &quot;rg --files&quot;, 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.<br /> <br /> # '''Keep data separate from code where possible'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search&quot;.<br /> # '''Limit maximum number of threads for searches'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search-&gt;Ripgrep: Max Threads&quot; in order to limit the performance impact.<br /> <br /> ====Clean up when done====<br /> 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.<br /> <br /> # '''Shortening the Remote-SSH Reconnection Grace Time'''<br /> #: You can configure the Remote-SSH extension to reduce this time to something reasonable (e.g. 5 minutes).<br /> #: This can be done by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching &quot;Remote-SSH: Settings&quot;.<br /> #: [[File:VSCode-remotesshsettings.jpg|alt=Under the Command Palette menu, &quot;Remote-SSH: Settings&quot; is searched.]]<br /> #: This will open a dialog box with settings for the Remote-SSH extension. From here, you can scroll down or search for &quot;Remote.SSH: Reconnection Grace Time&quot; and configure this to something reasonable.<br /> #: [[File:VSCode-reconnectiongracetime.jpg|alt=In the &quot;Settings&quot; dialog box, &quot;Remote.SSH: Reconnection Grace Time&quot; is overridden to 300 seconds.]]<br /> # '''Manually killing a remote VS Code server'''<br /> #: 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 &quot;Kill VS Code Server on Host...&quot;.<br /> #: [[File:VSCode-killremote1.png|alt=Under the Command Palette menu, &quot;Kill VS Code Server on Host...&quot; is searched.]]<br /> #: Select the submission node you were using and click on it.<br /> #: [[File:VSCode-killremote2.png|alt='nexus' is searched and a 2 submission nodes pop up as matching searches.]]<br /> #: Wait a few seconds and you should get a message confirming the command went through.<br /> #: [[File:VSCode-killremote3.png|alt=Pop-up confirming the kill command went through.]]<br /> #: The next time you connect to the same submission node, you will have a fresh VS Code session on it.<br /> <br /> ===Running VS Code on a Compute Node===<br /> 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.<br /> <br /> # SSH to your submission node.<br /> # Open a [[Tmux]] session for your salloc command. salloc will only hold your allocation if you don't close your shell, so tmux is a convenient way to keep a persistent shell open on the submission node.<br /> # In your tmux session on the submission node, use &lt;code&gt;salloc&lt;/code&gt; to request an allocation on a compute node. Once allocated, it will print hostname of the compute node which you were allocated.<br /> #* Example: &lt;code&gt;salloc --mem=4G --cpus-per-task=2&lt;/code&gt;<br /> #* You can adjust the memory, CPUs, and time limit as needed.<br /> #* Without any other arguments, this allocation will be on the [[Nexus/Tron | tron]] partition, subject to the &lt;code&gt;default&lt;/code&gt; QoS resource limits. If you need resources beyond what the default QoS allows, you can adjust the account/partition/QoS assigned to the allocation as you can with any other job.<br /> #*: [[File:Salloc example.png|thumb|400px|none|Example of output from running salloc.]]<br /> # On your local machine, use the Remote-SSH plugin on VS Code to connect directly to the compute node.<br /> #: [[File:Add remote.png|thumb|400px|none|If the compute node is not defined, press the &quot;+&quot; 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.]]<br /> <br /> ==Common Issues==<br /> If you are having trouble [[SSH]]'ing to a submission node with VS Code, check if your home directory is full.<br /> <br /> # Connect to one of your Nexus submission nodes via [[SSH]] '''not''' using VS Code.<br /> # Navigate to your home directory. &lt;pre&gt;cd ~&lt;/pre&gt;<br /> # Check if it is full. &lt;pre&gt;df -h .&lt;/pre&gt;<br /> # If it is full (Avail 0), delete some files to free up at least ~100MB of space. &lt;pre&gt;Filesystem Size Used Avail Use% Mounted on&amp;#10;data.isilon.umiacs.umd.edu:/ifs/umiacs/homes 30G 30G 0 100% /fs/nfshomes&lt;/pre&gt;<br /> # Try connecting with VS Code again.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=VS_Code&diff=13411 2026-09-24T17:22:12Z

<p>Mbaney: /* Running VS Code on a Compute Node */</p> <hr /> <div>[https://code.visualstudio.com/ Visual Studio (VS) Code] is a multi-platform source-code editor developed by Microsoft. It can be used with a variety of programming languages and can have its base functionality extended through extensions available via its [https://marketplace.visualstudio.com/vscode marketplace]. The base editor itself is free, but some extensions may require paid subscriptions.<br /> <br /> There are also forks/open source alternatives of VS Code, such as [https://www.cursor.com Cursor] or [https://vscodium.com/ VSCodium]. The same general principals below apply to these editors as well.<br /> <br /> ==Cluster Usage==<br /> 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.<br /> <br /> 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].<br /> <br /> ===Running VS Code on a Compute Node===<br /> 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.<br /> <br /> # SSH to your submission node.<br /> # Open a [[Tmux]] session for your salloc command. salloc will only hold your allocation if you don't close your shell, so tmux is a convenient way to keep a persistent shell open on the submission node.<br /> # In your tmux session on the submission node, use &lt;code&gt;salloc&lt;/code&gt; to request an allocation on a compute node. Once allocated, it will print hostname of the compute node which you were allocated.<br /> #* Example: &lt;code&gt;salloc --mem=4G --cpus-per-task=2&lt;/code&gt;<br /> #* You can adjust the memory, CPUs, and time limit as needed.<br /> #* Without any other arguments, this allocation will be on the [[Nexus/Tron | tron]] partition, subject to the &lt;code&gt;default&lt;/code&gt; QoS resource limits. If you need resources beyond what the default QoS allows, you can adjust the account/partition/QoS assigned to the allocation as you can with any other job.<br /> #*: [[File:Salloc example.png|thumb|400px|none|Example of output from running salloc.]]<br /> # On your local machine, use the Remote-SSH plugin on VS Code to connect directly to the compute node.<br /> #: [[File:Add remote.png|thumb|400px|none|If the compute node is not defined, press the &quot;+&quot; 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.]]<br /> <br /> ===Best Practices===<br /> Because of the multi-tenant nature of our submission nodes, using the Remote - SSH extension to connect to a VS Code Server running on a submission node can have adverse affects on other users simultaneously using the submission nodes if not properly managed. The following is a list of &quot;best practices&quot; that we ask you please follow to minimize the chance of impacting others on submission nodes. We have compiled the list through observation as well as through discussion with users.<br /> <br /> ====Use only as a code editor====<br /> VS Code can perform many common file management operations, such as moving, copying, or deleting files or directories. However, the overhead of providing progress updates / status messages through VS Code's UI can cause load spikes that result in other system-level and user processes on the submission node slowing down. This is especially the case if operating on thousands to millions of small image or video files. In extreme cases, it can seem as though the submission node is wholly unresponsive.<br /> <br /> The best way to combat this is to use VS Code as just a code editor as strictly as you can (meaning creating new and/or editing existing source code files only). Use standard command-line programs such as &lt;code&gt;mv&lt;/code&gt;/&lt;code&gt;cp&lt;/code&gt;/&lt;code&gt;rm&lt;/code&gt; in VS Code's terminal window or a separate application's terminal window for local file management instead, or use the techniques advertised [[LocalDataTransfer | here]] for larger data transfers between nodes.<br /> <br /> ====Do not open large files====<br /> Files that you open in VS Code's text editor on a remote machine through the Remote - SSH extension are loaded entirely into RAM on the remote machine. Because of the persistence of VS Code Server processes, opening several unique files may result in them all remaining in RAM for extended periods of time even if you no longer have tabs open for them in the Tab Bar.<br /> <br /> As such, please refrain from opening large files (more than a few MB) in VS Code itself on submission nodes. Use a lighter-weight command-line based text editor such as [https://www.vim.org vim] or otherwise in VS Code's terminal window or a separate application's terminal window for local file editing instead.<br /> <br /> If you absolutely need to open one or more large files for a very brief period of time on a submission node, please clean up your server session on that node (see below section) as soon as possible when done.<br /> <br /> ====Ripgrep====<br /> 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 &quot;rg --files&quot;, 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.<br /> <br /> # '''Keep data separate from code where possible'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search&quot;.<br /> # '''Limit maximum number of threads for searches'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search-&gt;Ripgrep: Max Threads&quot; in order to limit the performance impact.<br /> <br /> ====Clean up when done====<br /> 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.<br /> <br /> # '''Shortening the Remote-SSH Reconnection Grace Time'''<br /> #: You can configure the Remote-SSH extension to reduce this time to something reasonable (e.g. 5 minutes).<br /> #: This can be done by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching &quot;Remote-SSH: Settings&quot;.<br /> #: [[File:VSCode-remotesshsettings.jpg|alt=Under the Command Palette menu, &quot;Remote-SSH: Settings&quot; is searched.]]<br /> #: This will open a dialog box with settings for the Remote-SSH extension. From here, you can scroll down or search for &quot;Remote.SSH: Reconnection Grace Time&quot; and configure this to something reasonable.<br /> #: [[File:VSCode-reconnectiongracetime.jpg|alt=In the &quot;Settings&quot; dialog box, &quot;Remote.SSH: Reconnection Grace Time&quot; is overridden to 300 seconds.]]<br /> # '''Manually killing a remote VS Code server'''<br /> #: 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 &quot;Kill VS Code Server on Host...&quot;.<br /> #: [[File:VSCode-killremote1.png|alt=Under the Command Palette menu, &quot;Kill VS Code Server on Host...&quot; is searched.]]<br /> #: Select the submission node you were using and click on it.<br /> #: [[File:VSCode-killremote2.png|alt='nexus' is searched and a 2 submission nodes pop up as matching searches.]]<br /> #: Wait a few seconds and you should get a message confirming the command went through.<br /> #: [[File:VSCode-killremote3.png|alt=Pop-up confirming the kill command went through.]]<br /> #: The next time you connect to the same submission node, you will have a fresh VS Code session on it.<br /> <br /> ==Common Issues==<br /> If you are having trouble [[SSH]]'ing to a submission node with VS Code, check if your home directory is full.<br /> <br /> # Connect to one of your Nexus submission nodes via [[SSH]] '''not''' using VS Code.<br /> # Navigate to your home directory. &lt;pre&gt;cd ~&lt;/pre&gt;<br /> # Check if it is full. &lt;pre&gt;df -h .&lt;/pre&gt;<br /> # If it is full (Avail 0), delete some files to free up at least ~100MB of space. &lt;pre&gt;Filesystem Size Used Avail Use% Mounted on&amp;#10;data.isilon.umiacs.umd.edu:/ifs/umiacs/homes 30G 30G 0 100% /fs/nfshomes&lt;/pre&gt;<br /> # Try connecting with VS Code again.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=VS_Code&diff=13410 2026-09-24T17:20:50Z

<p>Mbaney: /* Running VS Code on a Compute Node */</p> <hr /> <div>[https://code.visualstudio.com/ Visual Studio (VS) Code] is a multi-platform source-code editor developed by Microsoft. It can be used with a variety of programming languages and can have its base functionality extended through extensions available via its [https://marketplace.visualstudio.com/vscode marketplace]. The base editor itself is free, but some extensions may require paid subscriptions.<br /> <br /> There are also forks/open source alternatives of VS Code, such as [https://www.cursor.com Cursor] or [https://vscodium.com/ VSCodium]. The same general principals below apply to these editors as well.<br /> <br /> ==Cluster Usage==<br /> 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.<br /> <br /> 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].<br /> <br /> ===Running VS Code on a Compute Node===<br /> 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.<br /> <br /> # SSH to your submission node.<br /> # Open a [[Tmux]] session for your salloc command. salloc will only hold your allocation if you don't close your shell, so tmux is a convenient way to keep a persistent shell open on the submission node.<br /> # In your tmux session on the submission node, use &lt;code&gt;salloc&lt;/code&gt; to request an allocation on a compute node. Once allocated, it will print hostname of the compute node which you were allocated.<br /> #* Example: &lt;code&gt;salloc --mem=4G --cpus-per-task=2&lt;/code&gt;<br /> #* You can adjust the memory, CPUs, and time limit as needed.<br /> #* Without any other arguments, this allocation will be on the &lt;code&gt;tron&lt;/code&gt; partition, subject to the &lt;code&gt;default&lt;/code&gt; QoS resource limits. If you need resources beyond what the default QoS allows, you can adjust the account/partition/QoS assigned to the allocation as you can with any other job.<br /> #*: [[File:Salloc example.png|thumb|400px|none|Example of output from running salloc.]]<br /> # On your local machine, use the Remote-SSH plugin on VS Code to connect directly to the compute node.<br /> #: [[File:Add remote.png|thumb|400px|none|If the compute node is not defined, press the &quot;+&quot; 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.]]<br /> <br /> ===Best Practices===<br /> Because of the multi-tenant nature of our submission nodes, using the Remote - SSH extension to connect to a VS Code Server running on a submission node can have adverse affects on other users simultaneously using the submission nodes if not properly managed. The following is a list of &quot;best practices&quot; that we ask you please follow to minimize the chance of impacting others on submission nodes. We have compiled the list through observation as well as through discussion with users.<br /> <br /> ====Use only as a code editor====<br /> VS Code can perform many common file management operations, such as moving, copying, or deleting files or directories. However, the overhead of providing progress updates / status messages through VS Code's UI can cause load spikes that result in other system-level and user processes on the submission node slowing down. This is especially the case if operating on thousands to millions of small image or video files. In extreme cases, it can seem as though the submission node is wholly unresponsive.<br /> <br /> The best way to combat this is to use VS Code as just a code editor as strictly as you can (meaning creating new and/or editing existing source code files only). Use standard command-line programs such as &lt;code&gt;mv&lt;/code&gt;/&lt;code&gt;cp&lt;/code&gt;/&lt;code&gt;rm&lt;/code&gt; in VS Code's terminal window or a separate application's terminal window for local file management instead, or use the techniques advertised [[LocalDataTransfer | here]] for larger data transfers between nodes.<br /> <br /> ====Do not open large files====<br /> Files that you open in VS Code's text editor on a remote machine through the Remote - SSH extension are loaded entirely into RAM on the remote machine. Because of the persistence of VS Code Server processes, opening several unique files may result in them all remaining in RAM for extended periods of time even if you no longer have tabs open for them in the Tab Bar.<br /> <br /> As such, please refrain from opening large files (more than a few MB) in VS Code itself on submission nodes. Use a lighter-weight command-line based text editor such as [https://www.vim.org vim] or otherwise in VS Code's terminal window or a separate application's terminal window for local file editing instead.<br /> <br /> If you absolutely need to open one or more large files for a very brief period of time on a submission node, please clean up your server session on that node (see below section) as soon as possible when done.<br /> <br /> ====Ripgrep====<br /> 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 &quot;rg --files&quot;, 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.<br /> <br /> # '''Keep data separate from code where possible'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search&quot;.<br /> # '''Limit maximum number of threads for searches'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search-&gt;Ripgrep: Max Threads&quot; in order to limit the performance impact.<br /> <br /> ====Clean up when done====<br /> 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.<br /> <br /> # '''Shortening the Remote-SSH Reconnection Grace Time'''<br /> #: You can configure the Remote-SSH extension to reduce this time to something reasonable (e.g. 5 minutes).<br /> #: This can be done by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching &quot;Remote-SSH: Settings&quot;.<br /> #: [[File:VSCode-remotesshsettings.jpg|alt=Under the Command Palette menu, &quot;Remote-SSH: Settings&quot; is searched.]]<br /> #: This will open a dialog box with settings for the Remote-SSH extension. From here, you can scroll down or search for &quot;Remote.SSH: Reconnection Grace Time&quot; and configure this to something reasonable.<br /> #: [[File:VSCode-reconnectiongracetime.jpg|alt=In the &quot;Settings&quot; dialog box, &quot;Remote.SSH: Reconnection Grace Time&quot; is overridden to 300 seconds.]]<br /> # '''Manually killing a remote VS Code server'''<br /> #: 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 &quot;Kill VS Code Server on Host...&quot;.<br /> #: [[File:VSCode-killremote1.png|alt=Under the Command Palette menu, &quot;Kill VS Code Server on Host...&quot; is searched.]]<br /> #: Select the submission node you were using and click on it.<br /> #: [[File:VSCode-killremote2.png|alt='nexus' is searched and a 2 submission nodes pop up as matching searches.]]<br /> #: Wait a few seconds and you should get a message confirming the command went through.<br /> #: [[File:VSCode-killremote3.png|alt=Pop-up confirming the kill command went through.]]<br /> #: The next time you connect to the same submission node, you will have a fresh VS Code session on it.<br /> <br /> ==Common Issues==<br /> If you are having trouble [[SSH]]'ing to a submission node with VS Code, check if your home directory is full.<br /> <br /> # Connect to one of your Nexus submission nodes via [[SSH]] '''not''' using VS Code.<br /> # Navigate to your home directory. &lt;pre&gt;cd ~&lt;/pre&gt;<br /> # Check if it is full. &lt;pre&gt;df -h .&lt;/pre&gt;<br /> # If it is full (Avail 0), delete some files to free up at least ~100MB of space. &lt;pre&gt;Filesystem Size Used Avail Use% Mounted on&amp;#10;data.isilon.umiacs.umd.edu:/ifs/umiacs/homes 30G 30G 0 100% /fs/nfshomes&lt;/pre&gt;<br /> # Try connecting with VS Code again.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=VS_Code&diff=13409 2026-09-24T17:20:11Z

<p>Mbaney: </p> <hr /> <div>[https://code.visualstudio.com/ Visual Studio (VS) Code] is a multi-platform source-code editor developed by Microsoft. It can be used with a variety of programming languages and can have its base functionality extended through extensions available via its [https://marketplace.visualstudio.com/vscode marketplace]. The base editor itself is free, but some extensions may require paid subscriptions.<br /> <br /> There are also forks/open source alternatives of VS Code, such as [https://www.cursor.com Cursor] or [https://vscodium.com/ VSCodium]. The same general principals below apply to these editors as well.<br /> <br /> ==Cluster Usage==<br /> 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.<br /> <br /> 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].<br /> <br /> ===Running VS Code on a Compute Node===<br /> 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.<br /> <br /> # SSH to your submission node.<br /> # Open a [[Tmux]] session for your salloc command. salloc will only hold your allocation if you don't close your shell, so tmux is a convenient way to keep a persistent shell open on the submission node.<br /> # In your tmux session on the submission node, use &lt;code&gt;salloc&lt;/code&gt; to request an allocation on a compute node. Once allocated, it will print hostname of the compute node which you were allocated.<br /> #* Example: &lt;code&gt;salloc --mem=4G --cpus-per-task=2 --time=08:00:00&lt;/code&gt;<br /> #* You can adjust the memory, CPUs, and time limit as needed.<br /> #* Without any other arguments, this allocation will be on the &lt;code&gt;tron&lt;/code&gt; partition, subject to the &lt;code&gt;default&lt;/code&gt; QoS resource limits. If you need resources beyond what the default QoS allows, you can adjust the account/partition/QoS assigned to the allocation as you can with any other job.<br /> #*: [[File:Salloc example.png|thumb|400px|none|Example of output from running salloc.]]<br /> # On your local machine, use the Remote-SSH plugin on VS Code to connect directly to the compute node.<br /> #: [[File:Add remote.png|thumb|400px|none|If the compute node is not defined, press the &quot;+&quot; 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.]]<br /> <br /> ===Best Practices===<br /> Because of the multi-tenant nature of our submission nodes, using the Remote - SSH extension to connect to a VS Code Server running on a submission node can have adverse affects on other users simultaneously using the submission nodes if not properly managed. The following is a list of &quot;best practices&quot; that we ask you please follow to minimize the chance of impacting others on submission nodes. We have compiled the list through observation as well as through discussion with users.<br /> <br /> ====Use only as a code editor====<br /> VS Code can perform many common file management operations, such as moving, copying, or deleting files or directories. However, the overhead of providing progress updates / status messages through VS Code's UI can cause load spikes that result in other system-level and user processes on the submission node slowing down. This is especially the case if operating on thousands to millions of small image or video files. In extreme cases, it can seem as though the submission node is wholly unresponsive.<br /> <br /> The best way to combat this is to use VS Code as just a code editor as strictly as you can (meaning creating new and/or editing existing source code files only). Use standard command-line programs such as &lt;code&gt;mv&lt;/code&gt;/&lt;code&gt;cp&lt;/code&gt;/&lt;code&gt;rm&lt;/code&gt; in VS Code's terminal window or a separate application's terminal window for local file management instead, or use the techniques advertised [[LocalDataTransfer | here]] for larger data transfers between nodes.<br /> <br /> ====Do not open large files====<br /> Files that you open in VS Code's text editor on a remote machine through the Remote - SSH extension are loaded entirely into RAM on the remote machine. Because of the persistence of VS Code Server processes, opening several unique files may result in them all remaining in RAM for extended periods of time even if you no longer have tabs open for them in the Tab Bar.<br /> <br /> As such, please refrain from opening large files (more than a few MB) in VS Code itself on submission nodes. Use a lighter-weight command-line based text editor such as [https://www.vim.org vim] or otherwise in VS Code's terminal window or a separate application's terminal window for local file editing instead.<br /> <br /> If you absolutely need to open one or more large files for a very brief period of time on a submission node, please clean up your server session on that node (see below section) as soon as possible when done.<br /> <br /> ====Ripgrep====<br /> 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 &quot;rg --files&quot;, 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.<br /> <br /> # '''Keep data separate from code where possible'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search&quot;.<br /> # '''Limit maximum number of threads for searches'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search-&gt;Ripgrep: Max Threads&quot; in order to limit the performance impact.<br /> <br /> ====Clean up when done====<br /> 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.<br /> <br /> # '''Shortening the Remote-SSH Reconnection Grace Time'''<br /> #: You can configure the Remote-SSH extension to reduce this time to something reasonable (e.g. 5 minutes).<br /> #: This can be done by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching &quot;Remote-SSH: Settings&quot;.<br /> #: [[File:VSCode-remotesshsettings.jpg|alt=Under the Command Palette menu, &quot;Remote-SSH: Settings&quot; is searched.]]<br /> #: This will open a dialog box with settings for the Remote-SSH extension. From here, you can scroll down or search for &quot;Remote.SSH: Reconnection Grace Time&quot; and configure this to something reasonable.<br /> #: [[File:VSCode-reconnectiongracetime.jpg|alt=In the &quot;Settings&quot; dialog box, &quot;Remote.SSH: Reconnection Grace Time&quot; is overridden to 300 seconds.]]<br /> # '''Manually killing a remote VS Code server'''<br /> #: 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 &quot;Kill VS Code Server on Host...&quot;.<br /> #: [[File:VSCode-killremote1.png|alt=Under the Command Palette menu, &quot;Kill VS Code Server on Host...&quot; is searched.]]<br /> #: Select the submission node you were using and click on it.<br /> #: [[File:VSCode-killremote2.png|alt='nexus' is searched and a 2 submission nodes pop up as matching searches.]]<br /> #: Wait a few seconds and you should get a message confirming the command went through.<br /> #: [[File:VSCode-killremote3.png|alt=Pop-up confirming the kill command went through.]]<br /> #: The next time you connect to the same submission node, you will have a fresh VS Code session on it.<br /> <br /> ==Common Issues==<br /> If you are having trouble [[SSH]]'ing to a submission node with VS Code, check if your home directory is full.<br /> <br /> # Connect to one of your Nexus submission nodes via [[SSH]] '''not''' using VS Code.<br /> # Navigate to your home directory. &lt;pre&gt;cd ~&lt;/pre&gt;<br /> # Check if it is full. &lt;pre&gt;df -h .&lt;/pre&gt;<br /> # If it is full (Avail 0), delete some files to free up at least ~100MB of space. &lt;pre&gt;Filesystem Size Used Avail Use% Mounted on&amp;#10;data.isilon.umiacs.umd.edu:/ifs/umiacs/homes 30G 30G 0 100% /fs/nfshomes&lt;/pre&gt;<br /> # Try connecting with VS Code again.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=VS_Code&diff=13408 2026-09-24T16:54:10Z

<p>Mbaney: </p> <hr /> <div>[https://code.visualstudio.com/ Visual Studio (VS) Code] is a multi-platform source-code editor developed by Microsoft. It can be used with a variety of programming languages and can have its base functionality extended through extensions available via its [https://marketplace.visualstudio.com/vscode marketplace]. The base editor itself is free, but some extensions may require paid subscriptions.<br /> <br /> There are also forks/open source alternatives of VS Code, such as [https://www.cursor.com Cursor] or [https://vscodium.com/ VSCodium]. The same general principals below apply to these editors as well.<br /> <br /> ==Cluster Usage==<br /> 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.<br /> <br /> 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].<br /> <br /> ===Running VS Code on a Compute Node===<br /> 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.<br /> <br /> # SSH to your submission node.<br /> # Open a [[Tmux]] session for your salloc command. salloc will only hold your allocation if you don't close your shell, so tmux is a convenient way to keep a persistent shell open on the submission node.<br /> # In your tmux session on the submission node, use &lt;code&gt;salloc&lt;/code&gt; to request an allocation on a compute node. Once allocated, it will print hostname of the compute node which you were allocated.<br /> #* Example: &lt;code&gt;salloc --partition=tron --mem=4G --cpus-per-task=2 --time=1-00:00:00&lt;/code&gt;<br /> #* You can adjust the memory, CPUs, and time limit as needed.<br /> #*: [[File:Salloc example.png|thumb|400px|none|Example of output from running salloc.]]<br /> # On your local machine, use the Remote-SSH plugin on VS Code to connect directly to the compute node.<br /> #: [[File:Add remote.png|thumb|400px|none|If the compute node is not defined, press the &quot;+&quot; 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.]]<br /> <br /> ===Best Practices===<br /> Because of the multi-tenant nature of our submission nodes, using the Remote - SSH extension to connect to a VS Code Server running on a submission node can have adverse affects on other users simultaneously using the submission nodes if not properly managed. The following is a list of &quot;best practices&quot; that we ask you please follow to minimize the chance of impacting others on submission nodes. We have compiled the list through observation as well as through discussion with users.<br /> <br /> ====Use only as a code editor====<br /> VS Code can perform many common file management operations, such as moving, copying, or deleting files or directories. However, the overhead of providing progress updates / status messages through VS Code's UI can cause load spikes that result in other system-level and user processes on the submission node slowing down. This is especially the case if operating on thousands to millions of small image or video files. In extreme cases, it can seem as though the submission node is wholly unresponsive.<br /> <br /> The best way to combat this is to use VS Code as just a code editor as strictly as you can (meaning creating new and/or editing existing source code files only). Use standard command-line programs such as &lt;code&gt;mv&lt;/code&gt;/&lt;code&gt;cp&lt;/code&gt;/&lt;code&gt;rm&lt;/code&gt; in VS Code's terminal window or a separate application's terminal window for local file management instead, or use the techniques advertised [[LocalDataTransfer | here]] for larger data transfers between nodes.<br /> <br /> ====Do not open large files====<br /> Files that you open in VS Code's text editor on a remote machine through the Remote - SSH extension are loaded entirely into RAM on the remote machine. Because of the persistence of VS Code Server processes, opening several unique files may result in them all remaining in RAM for extended periods of time even if you no longer have tabs open for them in the Tab Bar.<br /> <br /> As such, please refrain from opening large files (more than a few MB) in VS Code itself on submission nodes. Use a lighter-weight command-line based text editor such as [https://www.vim.org vim] or otherwise in VS Code's terminal window or a separate application's terminal window for local file editing instead.<br /> <br /> If you absolutely need to open one or more large files for a very brief period of time on a submission node, please clean up your server session on that node (see below section) as soon as possible when done.<br /> <br /> ====Ripgrep====<br /> 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 &quot;rg --files&quot;, 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.<br /> <br /> # '''Keep data separate from code where possible'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search&quot;.<br /> # '''Limit maximum number of threads for searches'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search-&gt;Ripgrep: Max Threads&quot; in order to limit the performance impact.<br /> <br /> ====Clean up when done====<br /> 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.<br /> <br /> # '''Shortening the Remote-SSH Reconnection Grace Time'''<br /> #: You can configure the Remote-SSH extension to reduce this time to something reasonable (e.g. 5 minutes).<br /> #: This can be done by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching &quot;Remote-SSH: Settings&quot;.<br /> #: [[File:VSCode-remotesshsettings.jpg|alt=Under the Command Palette menu, &quot;Remote-SSH: Settings&quot; is searched.]]<br /> #: This will open a dialog box with settings for the Remote-SSH extension. From here, you can scroll down or search for &quot;Remote.SSH: Reconnection Grace Time&quot; and configure this to something reasonable.<br /> #: [[File:VSCode-reconnectiongracetime.jpg|alt=In the &quot;Settings&quot; dialog box, &quot;Remote.SSH: Reconnection Grace Time&quot; is overridden to 300 seconds.]]<br /> # '''Manually killing a remote VS Code server'''<br /> #: 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 &quot;Kill VS Code Server on Host...&quot;.<br /> #: [[File:VSCode-killremote1.png|alt=Under the Command Palette menu, &quot;Kill VS Code Server on Host...&quot; is searched.]]<br /> #: Select the submission node you were using and click on it.<br /> #: [[File:VSCode-killremote2.png|alt='nexus' is searched and a 2 submission nodes pop up as matching searches.]]<br /> #: Wait a few seconds and you should get a message confirming the command went through.<br /> #: [[File:VSCode-killremote3.png|alt=Pop-up confirming the kill command went through.]]<br /> #: The next time you connect to the same submission node, you will have a fresh VS Code session on it.<br /> <br /> ==Common Issues==<br /> If you are having trouble [[SSH]]'ing to a submission node with VS Code, check if your home directory is full.<br /> <br /> # Connect to one of your Nexus submission nodes via [[SSH]] '''not''' using VS Code.<br /> # Navigate to your home directory. &lt;pre&gt;cd ~&lt;/pre&gt;<br /> # Check if it is full. &lt;pre&gt;df -h .&lt;/pre&gt;<br /> # If it is full (Avail 0), delete some files to free up at least ~100MB of space. &lt;pre&gt;Filesystem Size Used Avail Use% Mounted on&amp;#10;data.isilon.umiacs.umd.edu:/ifs/umiacs/homes 30G 30G 0 100% /fs/nfshomes&lt;/pre&gt;<br /> # Try connecting with VS Code again.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=VS_Code&diff=13400 2026-09-23T13:40:25Z

<p>Mbaney: </p> <hr /> <div>[https://code.visualstudio.com/ Visual Studio (VS) Code] is a multi-platform source-code editor developed by Microsoft. It can be used with a variety of programming languages and can have its base functionality extended through extensions available via its [https://marketplace.visualstudio.com/vscode marketplace]. The base editor itself is free, but some extensions may require paid subscriptions.<br /> <br /> There are also forks/open source alternatives of VS Code, such as [https://www.cursor.com Cursor] or [https://vscodium.com/ VSCodium]. The same general principals below apply to these editors as well.<br /> <br /> ==Cluster Usage==<br /> 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.<br /> <br /> 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].<br /> <br /> ===Best Practices===<br /> Because of the multi-tenant nature of our submission nodes, using the Remote - SSH extension to connect to a VS Code Server running on a submission node can have adverse affects on other users simultaneously using the submission nodes if not properly managed. The following is a list of &quot;best practices&quot; that we ask you please follow to minimize the chance of impacting others on submission nodes. We have compiled the list through observation as well as through discussion with users.<br /> <br /> ====Use only as a code editor====<br /> VS Code can perform many common file management operations, such as moving, copying, or deleting files or directories. However, the overhead of providing progress updates / status messages through VS Code's UI can cause load spikes that result in other system-level and user processes on the submission node slowing down. This is especially the case if operating on thousands to millions of small image or video files. In extreme cases, it can seem as though the submission node is wholly unresponsive.<br /> <br /> The best way to combat this is to use VS Code as just a code editor as strictly as you can (meaning creating new and/or editing existing source code files only). Use standard command-line programs such as &lt;code&gt;mv&lt;/code&gt;/&lt;code&gt;cp&lt;/code&gt;/&lt;code&gt;rm&lt;/code&gt; in VS Code's terminal window or a separate application's terminal window for local file management instead, or use the techniques advertised [[LocalDataTransfer | here]] for larger data transfers between nodes.<br /> <br /> ====Do not open large files====<br /> Files that you open in VS Code's text editor on a remote machine through the Remote - SSH extension are loaded entirely into RAM on the remote machine. Because of the persistence of VS Code Server processes, opening several unique files may result in them all remaining in RAM for extended periods of time even if you no longer have tabs open for them in the Tab Bar.<br /> <br /> As such, please refrain from opening large files (more than a few MB) in VS Code itself on submission nodes. Use a lighter-weight command-line based text editor such as [https://www.vim.org vim] or otherwise in VS Code's terminal window or a separate application's terminal window for local file editing instead.<br /> <br /> If you absolutely need to open one or more large files for a very brief period of time on a submission node, please clean up your server session on that node (see below section) as soon as possible when done.<br /> <br /> ====Ripgrep====<br /> 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 &quot;rg --files&quot;, 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.<br /> <br /> # '''Keep data separate from code where possible'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search&quot;.<br /> # '''Limit maximum number of threads for searches'''<br /> #: 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 &quot;Settings-&gt;Features-&gt;Search-&gt;Ripgrep: Max Threads&quot; in order to limit the performance impact.<br /> <br /> ====Clean up when done====<br /> 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.<br /> <br /> # '''Shortening the Remote-SSH Reconnection Grace Time'''<br /> #: You can configure the Remote-SSH extension to reduce this time to something reasonable (e.g. 5 minutes).<br /> #: This can be done by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching &quot;Remote-SSH: Settings&quot;.<br /> #: [[File:VSCode-remotesshsettings.jpg|alt=Under the Command Palette menu, &quot;Remote-SSH: Settings&quot; is searched.]]<br /> #: This will open a dialog box with settings for the Remote-SSH extension. From here, you can scroll down or search for &quot;Remote.SSH: Reconnection Grace Time&quot; and configure this to something reasonable.<br /> #: [[File:VSCode-reconnectiongracetime.jpg|alt=In the &quot;Settings&quot; dialog box, &quot;Remote.SSH: Reconnection Grace Time&quot; is overridden to 300 seconds.]]<br /> # '''Manually killing a remote VS Code server'''<br /> #: 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 &quot;Kill VS Code Server on Host...&quot;.<br /> #: [[File:VSCode-killremote1.png|alt=Under the Command Palette menu, &quot;Kill VS Code Server on Host...&quot; is searched.]]<br /> #: Select the submission node you were using and click on it.<br /> #: [[File:VSCode-killremote2.png|alt='nexus' is searched and a 2 submission nodes pop up as matching searches.]]<br /> #: Wait a few seconds and you should get a message confirming the command went through.<br /> #: [[File:VSCode-killremote3.png|alt=Pop-up confirming the kill command went through.]]<br /> #: The next time you connect to the same submission node, you will have a fresh VS Code session on it.<br /> <br /> ==Common Issues==<br /> If you are having trouble [[SSH]]'ing to a submission node with VS Code, check if your home directory is full.<br /> <br /> # Connect to one of your Nexus submission nodes via [[SSH]] '''not''' using VS Code.<br /> # Navigate to your home directory. &lt;pre&gt;cd ~&lt;/pre&gt;<br /> # Check if it is full. &lt;pre&gt;df -h .&lt;/pre&gt;<br /> # If it is full (Avail 0), delete some files to free up at least ~100MB of space. &lt;pre&gt;Filesystem Size Used Avail Use% Mounted on&amp;#10;data.isilon.umiacs.umd.edu:/ifs/umiacs/homes 30G 30G 0 100% /fs/nfshomes&lt;/pre&gt;<br /> # Try connecting with VS Code again.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=VS_Code&diff=13399 2026-09-23T13:33:20Z

<p>Mbaney: </p> <hr /> <div>[https://code.visualstudio.com/ Visual Studio (VS) Code] is a multi-platform source-code editor developed by Microsoft. It can be used with a variety of programming languages and can have its base functionality extended through extensions available via its [https://marketplace.visualstudio.com/vscode marketplace]. The base editor itself is free, but some extensions may require paid subscriptions.<br /> <br /> There are also forks/open source alternatives of VS Code, such as [https://www.cursor.com Cursor] or [https://vscodium.com/ VSCodium]. The same general principals below apply to these editors as well.<br /> <br /> ==Cluster Usage==<br /> 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.<br /> <br /> 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].<br /> <br /> ===Best Practices===<br /> Because of the multi-tenant nature of our submission nodes, using the Remote - SSH extension to connect to a VS Code Server running on a submission node can have adverse affects on other users simultaneously using the submission nodes if not properly managed. The following is a list of &quot;best practices&quot; that we ask you please follow to minimize the chance of impacting others on submission nodes. We have compiled the list through observation as well as through discussion with users.<br /> <br /> ====Use only as a code editor====<br /> VS Code can perform many common file management operations, such as moving, copying, or deleting files or directories. However, the overhead of providing progress updates / status messages through VS Code's UI can cause load spikes that result in other system-level and user processes on the submission node slowing down. This is especially the case if operating on thousands to millions of small image or video files. In extreme cases, it can seem as though the submission node is wholly unresponsive.<br /> <br /> The best way to combat this is to use VS Code as just a code editor as strictly as you can (meaning creating new and/or editing existing source code files only). Use standard command-line programs such as &lt;code&gt;mv&lt;/code&gt;/&lt;code&gt;cp&lt;/code&gt;/&lt;code&gt;rm&lt;/code&gt; in VS Code's terminal window or a separate application's terminal window for local file management instead, or use the techniques advertised [[LocalDataTransfer | here]] for larger data transfers between nodes.<br /> <br /> ====Do not open large files====<br /> Files that you open in VS Code's text editor on a remote machine through the Remote - SSH extension are loaded entirely into RAM on the remote machine. Because of the persistence of VS Code Server processes, opening several unique files may result in them all remaining in RAM for extended periods of time even if you no longer have tabs open for them in the Tab Bar.<br /> <br /> As such, please refrain from opening large files (more than a few MB) in VS Code itself on submission nodes. Use a lighter-weight command-line based text editor such as [https://www.vim.org vim] or otherwise in VS Code's terminal window or a separate application's terminal window for local file editing instead.<br /> <br /> If you absolutely need to open one or more large files for a very brief period of time on a submission node, please clean up your server session on that node (see below section) as soon as possible when done.<br /> <br /> ====Ripgrep====<br /> 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 &quot;rg --files&quot;, 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.<br /> <br /> =====Keep data separate from code where possible=====<br /> 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 &quot;Settings-&gt;Features-&gt;Search&quot;.<br /> <br /> =====Limit maximum number of threads for searches=====<br /> 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 &quot;Settings-&gt;Features-&gt;Search-&gt;Ripgrep: Max Threads&quot; in order to limit the performance impact.<br /> <br /> ====Clean up when done====<br /> 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.<br /> <br /> =====Shortening the Remote-SSH Reconnection Grace Time=====<br /> You can configure the Remote-SSH extension to reduce this time to something reasonable (e.g. 5 minutes).<br /> <br /> This can be done by opening the [https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette Command Palette] (Ctrl+Shift+P) and searching &quot;Remote-SSH: Settings&quot;.<br /> <br /> : [[File:VSCode-remotesshsettings.jpg|alt=Under the Command Palette menu, &quot;Remote-SSH: Settings&quot; is searched.]]<br /> <br /> This will open a dialog box with settings for the Remote-SSH extension. From here, you can scroll down or search for &quot;Remote.SSH: Reconnection Grace Time&quot; and configure this to something reasonable.<br /> <br /> : [[File:VSCode-reconnectiongracetime.jpg|alt=In the &quot;Settings&quot; dialog box, &quot;Remote.SSH: Reconnection Grace Time&quot; is overridden to 300 seconds.]]<br /> <br /> =====Manually killing a remote VS Code server=====<br /> 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 &quot;Kill VS Code Server on Host...&quot;.<br /> <br /> : [[File:VSCode-killremote1.png|alt=Under the Command Palette menu, &quot;Kill VS Code Server on Host...&quot; is searched.]]<br /> <br /> Select the submission node you were using and click on it.<br /> <br /> : [[File:VSCode-killremote2.png|alt='nexus' is searched and a 2 submission nodes pop up as matching searches.]]<br /> <br /> Wait a few seconds and you should get a message confirming the command went through.<br /> <br /> : [[File:VSCode-killremote3.png|alt=Pop-up confirming the kill command went through.]]<br /> <br /> The next time you connect to the same submission node, you will have a fresh VS Code session on it.<br /> <br /> ==Common Issues==<br /> If you are having trouble [[SSH]]'ing to a submission node with VS Code, check if your home directory is full.<br /> <br /> # Connect to one of your Nexus submission nodes via [[SSH]] '''not''' using VS Code.<br /> # Navigate to your home directory. &lt;pre&gt;cd ~&lt;/pre&gt;<br /> # Check if it is full. &lt;pre&gt;df -h .&lt;/pre&gt;<br /> # If it is full (Avail 0), delete some files to free up at least ~100MB of space. &lt;pre&gt;Filesystem Size Used Avail Use% Mounted on&amp;#10;data.isilon.umiacs.umd.edu:/ifs/umiacs/homes 30G 30G 0 100% /fs/nfshomes&lt;/pre&gt;<br /> # Try connecting with VS Code again.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=SecureShell/MFA&diff=13398 2026-09-18T15:59:39Z

<p>Mbaney: </p> <hr /> <div>==Overview==<br /> UMIACS has rolled out multi-factor authentication requirements when using [[SSH]] to connect to our publicly-routable hosts to provide better account and data security. Publicly-routable hosts in the context of UMIACS are hosts that have an IP address in one of the following [https://en.wikipedia.org/wiki/Subnet subnets]:<br /> * 128.8.118.0/23<br /> * 128.8.120.0/23<br /> * 128.8.122.0/24<br /> * 128.8.124.0/24<br /> * 128.8.141.0/24<br /> * 129.2.30.0/26<br /> <br /> SSH has two different authentication methods that we currently support on all of our internal hosts: interactive password authentication and [[SSH/Keys | public key authentication]]. Multi-factor authentication-enabled SSH on our public-facing hosts only supports interactive password authentication, with the secondary factor coming from [https://it.umd.edu/multi-factor-authentication-mfa UMD's Duo instance]. We do not support public key based authentication and Duo multi-factor authentication on our public-facing hosts. Please note that unfortunately [https://en.wikipedia.org/wiki/Universal_2nd_Factor U2F] hardware tokens registered with Duo are not supported for SSH login specifically. Other hardware tokens such as a [https://www.yubico.com/products/yubikey-5-overview/ YubiKey] or [https://guide.duo.com/tokens Duo's own hardware token] will still work.<br /> <br /> ==Example==<br /> The initial command or session setup for connecting to a host with multi-factor authentication enabled over SSH is the same as one that does not have it enabled. Our example for connecting to a host over SSH can be found [[SecureShell#Connecting_to_an_SSH_Server | here]]. In the below example, we are also SSH-ing to a [[Nexus]] node e.g. &lt;code&gt;ssh username@nexusgroup.umiacs.umd.edu&lt;/code&gt;<br /> <br /> Once you enter the command (if using a native terminal) or start the session (PuTTY or other terminal emulators), you will be presented with the following prompt:<br /> <br /> &lt;pre&gt;<br /> Password:<br /> &lt;/pre&gt;<br /> <br /> Enter your UMD passphrase here (the same as if you were using interactive password authentication to connect to an internal host). After correctly entering your password, you will be taken to the following prompt. '''Please note: The options shown here will vary depending on what/how many devices you have registered with UMD's Duo instance.''' In this example, we just have a single mobile phone with an active phone number and the Duo Mobile app installed.<br /> <br /> &lt;pre&gt;<br /> Password:<br /> Duo two-factor login for username<br /> <br /> Enter a passcode or select one of the following options:<br /> <br /> 1. Duo Push to XXX-XXX-1234<br /> 2. Phone call to XXX-XXX-1234<br /> <br /> Passcode or option (1-2):<br /> &lt;/pre&gt;<br /> (if you have a registered phone, the last 4 digits shown will be replaced with the last 4 digits of the phone number you specifically have registered)<br /> <br /> The numbered options here correspond to different methods that Duo can take to authenticate you, and are more or less identical to the options that would be presented to you via a GUI if you were attempting to sign into UMD's Duo elsewhere. <br /> <br /> ===Duo Push to ___===<br /> This will send a push notification to the Duo app on whichever device you chose for you to accept to proceed.<br /> <br /> &lt;pre&gt;<br /> Passcode or option (1-2): 1<br /> <br /> Pushed a login request to your device...<br /> &lt;/pre&gt;<br /> <br /> ===Phone call to XXX-XXX-XXXX===<br /> This will call your registered phone and ask you to press any key on your phone to proceed.<br /> <br /> &lt;pre&gt;<br /> Passcode or option (1-2): 2<br /> <br /> Calling your phone...<br /> Dialing XXX-XXX-1234...<br /> &lt;/pre&gt;<br /> <br /> (After answering) <br /> <br /> &lt;pre&gt;Answered. Press any key on your phone to log in.&lt;/pre&gt;<br /> <br /> ===Tap YubiKey===<br /> In addition, you can also simply tap the sensor on your YubiKey plugged into the device you are using to SSH to have it emit a string of characters and automatically hit Enter.<br /> <br /> &lt;pre&gt;<br /> Enter a passcode or select one of the following options:<br /> <br /> 1. Duo Push to XXX-XXX-1234<br /> 2. Phone call to XXX-XXX-1234<br /> <br /> Passcode or option (1-2): kffuastenhldrhfhadafdarivuntddugrvjvllddjjuget<br /> &lt;/pre&gt;<br /> <br /> ==Wrapping up==<br /> After finishing your method of choice for using Duo to multi-factor authenticate, you will be logged in and can operate as normal.<br /> &lt;pre&gt;<br /> Success. Logging you in...<br /> Last login: Wed Feb 17 12:00:00 2021 from ...<br /> [username@nexusgroup00 ~]$<br /> &lt;/pre&gt;<br /> <br /> Subsequent SSH attempts from the window you have already connected to will not require multi-factor authentication, even if the host you are trying to SSH to is another public-facing host. This is because the point of origin for the network traffic behind the connection attempt is now coming from within UMIACS' network border, rather than the rest of the internet.<br /> &lt;pre&gt;<br /> [username@nexusgroup00 ~]$ ssh nexusgroup01.umiacs.umd.edu<br /> username@nexusgroup01.umiacs.umd.edu's password:<br /> Last login: Wed Feb 17 11:59:00 2021 from ...<br /> [username@nexusgroup01 ~]$<br /> &lt;/pre&gt;<br /> <br /> ==Considerations==<br /> 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.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=SecureShell&diff=13397 2026-09-18T15:58:58Z

<p>Mbaney: /* Long Running Processes */</p> <hr /> <div>Secure Shell (or [http://en.wikipedia.org/wiki/Secure_Shell SSH]) is a network protocol allowing two computers to exchange data securely over an insecure network. By default, use of SSH brings the user to a terminal, but the protocol can be used for other types of data transfer such as [[SFTP]] and [[SCP]].<br /> <br /> ==Connecting to an SSH Server==<br /> Under Linux and macOS, the following command from a terminal will connect a client computer to the UMIACS [[Nexus]].<br /> # ssh username@nexusgroup.umiacs.umd.edu<br /> '''Note: Your Nexus submission node will vary depending on your sponsorship. See [[Nexus#Access|Nexus Access]] for more information.'''<br /> This will give you access to a terminal on any one of the [[Nexus]] servers. Note that by default you will not have access to applications that require X11 to run.<br /> <br /> All UMIACS-supported Windows hosts are installed with [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY]. If you are using a personal machine, you can either download and install PuTTY yourself, or if you are running a [https://docs.microsoft.com/en-us/lifecycle/products/windows-10-enterprise-and-education currently supported version of Windows], you can install the OpenSSH client natively in Windows by following Microsoft's instructions [https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse here]. Only the client is needed and not the server.<br /> <br /> ==X11 Forwarding==<br /> By default, SSH only gives the user shell access to a host. Enabling X11 Forwarding allows users to run applications with Graphical User Interfaces.<br /> <br /> Under Linux and macOS, the following command from a terminal will connect a client computer to the UMIACS [[Nexus]] using X11 Forwarding. Please note that under macOS, [http://xquartz.macosforge.org/landing/ xQuartz] is required on the client machine to forward X sessions from the remote session.<br /> # ssh '''-Y''' username@nexusgroup.umiacs.umd.edu<br /> '''Note: Your Nexus submission node will vary depending on your sponsorship. See [[Nexus#Access|Nexus Access]] for more information.'''<br /> <br /> Under Windows, you will need to forward X through [http://sourceforge.net/projects/vcxsrv/ VcXsrv] or another X11 application.<br /> <br /> If using PuTTY, you will need to enable X forwarding. The option is under Connection &gt; SSH &gt; X11, shown below.<br /> <br /> [[Image:Putty-x-forwarding.png |alt=Enabling X11 Forwarding in PuTTY settings]]<br /> <br /> If using the [https://learn.microsoft.com/en-us/windows/terminal/install Windows Terminal app], you will need to set an environment variable and then relaunch the app.<br /> :&lt;pre&gt;setx.exe DISPLAY &quot;127.0.0.1:0.0&quot;&lt;/pre&gt;<br /> <br /> After this has been done, every time you want to use X forwarding, you need to make sure VcXsrv or your other application has been started. If using VcXsrv, there will be an icon in your system tray.<br /> <br /> You will now be able to use Xwindow programs from your SSH client.<br /> <br /> ==SSH Tunneling==<br /> You can tunnel one or more ports through an SSH connection such that your packets will look like they are coming from the host you are tunneling to. This is helpful for services that you would be normally blocked by a firewall.<br /> <br /> Please see the [[SecureShellTunneling]] page for more information.<br /> <br /> ==SSH Keys (and Passwordless SSH)==<br /> SSH can utilize public key encryption to authenticate and authorize users. This can be considered more secure especially if you secure your private key with a pass-phrase. The keys themselves are not susceptible to brute force attacks like normal passwords over SSH are.<br /> <br /> Please see the [[SSH/Keys]] page for more information.<br /> <br /> '''Note: UMIACS still requires multi-factor authentication if you are connecting from the public internet or a [[VPN]] for security reasons. SSH keys can only be used when connecting to a UMIACS-supported host from another host already within UMIACS' network border.'''<br /> <br /> ==Verify remote host SSH fingerprint==<br /> <br /> The SSH protocol relies on host keys to verify the identity of a given host. Each host has a unique key for the various different protocols supported. <br /> <br /> When connecting to a remote host for the first time, you may see the following prompt:<br /> <br /> &lt;pre&gt;<br /> $ ssh username@nexusstaff.umiacs.umd.edu <br /> The authenticity of host 'nexusstaff.umiacs.umd.edu (128.8.132.230)' can't be established.<br /> ED25519 key fingerprint is: SHA256:N8+6sOAdq1NwvrpdHehe5MjQdnscNTBxvncqlHpt94o<br /> This key is not known by any other names.<br /> Are you sure you want to continue connecting (yes/no/[fingerprint])?<br /> &lt;/pre&gt;<br /> <br /> It is considered best practice to verify the key fingerprint with the actual key of the host. It is important to note that each key type has a different fingerprint. Depending on your local configuration, your client may prefer a specific type of key. The following commands retrieves all SSH public host keys from the server and prints out the fingerprints of each key in the MD5 format:<br /> <br /> &lt;pre&gt;<br /> $ ssh-keyscan nexusstaff.umiacs.umd.edu &gt; key<br /> $ ssh-keygen -l -E md5 -f key <br /> 3072 MD5:aa:8f:e7:95:3f:ee:7c:23:0f:6f:9a:64:78:49:25:37 nexusstaff.umiacs.umd.edu (RSA)<br /> 256 MD5:34:29:ea:73:98:98:e0:7b:d4:c3:83:50:bc:cb:b3:61 nexusstaff.umiacs.umd.edu (ECDSA)<br /> 256 MD5:02:50:b3:3e:d7:65:fb:08:54:30:f3:8d:7d:48:02:fc nexusstaff.umiacs.umd.edu (ED25519)<br /> &lt;/pre&gt;<br /> <br /> UMIACS maintains a reference of SSH key fingerprints available at the following link: <br /> https://intranet.umiacs.umd.edu/hostkeys<br /> <br /> If you have any questions, or notice a discrepancy, please [[HelpDesk | contact staff]].<br /> <br /> ===Windows / PuTTY Verification===<br /> If you use PuTTY to connect to remote hosts, the prompt will be similar to the following:<br /> <br /> [[File:Putty ssh host key prompt.png |alt=PuTTY SSH host key prompt]]<br /> <br /> If the host key reported by PuTTY matches the [https://gitlab.umiacs.umd.edu/staff/ssh-fingerprints/blob/master/fingerprints Documented entry for that host], it is safe to click 'yes'. If you notice a discrepancy, please [[HelpDesk | contact staff]].<br /> <br /> ===Other Platforms===<br /> * [https://winscp.net/eng/docs/faq_hostkey WinSCP]<br /> * [https://mobaxterm.mobatek.net/ MobaXterm]<br /> <br /> ==Remote Host Identification Has Changed==<br /> <br /> If a host key has changed since you last connected, you may see the following warning:<br /> <br /> &lt;pre&gt;<br /> $ ssh username@nexusstaff.umiacs.umd.edu <br /> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@<br /> @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @<br /> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@<br /> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!<br /> Someone could be eavesdropping on you right now (man-in-the-middle attack)!<br /> It is also possible that a host key has just been changed.<br /> The fingerprint for the ED25519 key sent by the remote host is<br /> SHA256:N8+6sOAdq1NwvrpdHehe5MjQdnscNTBxvncqlHpt94o.<br /> Please contact your system administrator.<br /> Add correct host key in /Users/username/.ssh/known_hosts to get rid of this message.<br /> Offending ED25519 key in /Users/username/.ssh/known_hosts:86<br /> Host key for nexusstaff.umiacs.umd.edu has changed and you have requested strict checking.<br /> Host key verification failed.<br /> &lt;/pre&gt;<br /> <br /> By default, SSH clients should refuse to connect when a remote host key has changed. If you see this warning, follow the instructions below to resolve.<br /> <br /> # [[#Verify remote host SSH fingerprint | Verify]] that the new fingerprint matches the fingerprint we publish at https://intranet.umiacs.umd.edu/hostkeys.<br /> # Once verified, open the known_hosts file and go to the line referenced in the warning (in this example, /Users/username/.ssh/known_hosts at line 86) and remove the entry. Next time you connect, it will prompt you as if it were your first time connecting to the host.<br /> &lt;strong&gt;NOTE:&lt;/strong&gt; This may need to be repeated if your known_hosts file has multiple types of keys for this host.<br /> <br /> ==Long Running Processes==<br /> 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.<br /> <br /> ==Further Information==<br /> * [https://www.openssh.com/ OpenSSH]<br /> * [https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse OpenSSH on Windows]</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=MonthlyMaintenanceWindow&diff=13396 2026-09-18T00:53:22Z

<p>Mbaney: </p> <hr /> <div>[[HelpDesk | UMIACS staff]] takes a monthly maintenance window to patch and reboot all UMIACS-supported hosts and services. This provides a way for staff to ensure security updates are installed and applied on the numerous different platforms and appliances that UMIACS runs.<br /> <br /> The window for each month is calculated by adding 9 days to [https://en.wikipedia.org/wiki/Patch_Tuesday Microsoft's Patch Tuesday] to allow for enough time to marshal patches released that month from Microsoft, Red Hat, Apple, and other OS and application vendors and have enough time to get systems prepared to reboot. This translates to the window being on the '''Thursday that occurs between the 17th and the 23rd (inclusive)''' of each month. The window lasts from '''5pm-8pm'''.<br /> <br /> [[Nexus]] will always have a reservation in place from 4:45pm-8pm on the day of the upcoming window to prevent jobs from being scheduled on compute nodes. The 15-minute addition before the start of the window is to allow jobs to fully end. Any job submitted before the reservation begins that has a time limit that would run into the reservation will be held until at least the end of the reservation - 8pm on the day of the window. This is to prevent issues with jobs failing to end properly causing delays in work we have scheduled during the window.<br /> <br /> A list of upcoming maintenance windows is as follows, with the next one in bold. Again, the window is on the '''Thursday that occurs between the 17th and the 23rd (inclusive)''' of each month, and lasts from '''5pm-8pm'''.<br /> <br /> <br /> * October 22nd 2026<br /> * November 19th 2026<br /> * December 17th 2026<br /> <br /> ==Archives==<br /> * January 17th 2013 - BEGIN time of 8pm-12am for this window through February 20th 2020<br /> * February 21st 2013<br /> * March 21st 2013<br /> * April 18th 2013<br /> * May 23rd 2013<br /> * June 20th 2013<br /> * July 18th 2013<br /> * August 22nd 2013<br /> * September 19th 2013<br /> * October 17th 2013<br /> * December 19th 2013<br /> * January 23rd 2014<br /> * February 20th 2014<br /> * March 20th 2014<br /> * April 17th 2014<br /> * May 22nd 2014<br /> * June 19th 2014<br /> * July 17th 2014<br /> * August 21st 2014<br /> * September 18th 2014<br /> * October 23rd 2014<br /> * November 20th 2014<br /> * December 18th 2014<br /> * January 22nd 2015<br /> * February 19th 2015<br /> * March 19th 2015<br /> * May 21st 2015<br /> * June 18th 2015<br /> * July 23rd 2015<br /> * August 20th 2015<br /> * September 17th 2015<br /> * October 22nd 2015<br /> * November 19th 2015<br /> * December 17th 2015<br /> * January 21st 2016<br /> * February 18th 2016<br /> * March 12th 2016 (Adjusted date for AVW power outage)<br /> * April 21st 2016<br /> * May 19th 2016<br /> * June 23rd 2016<br /> * July 21st 2016<br /> * August 18th 2016<br /> * September 22nd 2016<br /> * October 20th 2016<br /> * November 17th 2016<br /> * December 22nd 2016<br /> * January 19th 2017<br /> * February 23rd 2017<br /> * March 23rd 2017<br /> * April 20th 2017<br /> * May 18th 2017<br /> * June 22nd 2017<br /> * July 20th 2017<br /> * August 17th 2017<br /> * September 21st 2017<br /> * October 19th 2017<br /> * December 21st 2017<br /> * January 18th 2018<br /> * February 22nd 2018<br /> * March 22nd 2018<br /> * April 19th 2018<br /> * May 17th 2018<br /> * June 21st 2018<br /> * July 19th 2018<br /> * August 23rd 2018<br /> * September 20th 2018<br /> * October 18th 2018<br /> * December 20th 2018<br /> * January 24th 2019<br /> * February 21st 2019<br /> * April 18th 2019<br /> * May 23rd 2019<br /> * June 20th 2019<br /> * July 18th 2019<br /> * August 22nd 2019<br /> * September 19th 2019<br /> * October 17th 2019<br /> * November 21st 2019<br /> * December 19th 2019<br /> * January 23rd 2020<br /> * February 20th 2020<br /> * April 23rd 2020 - BEGIN time of 5pm-7pm for this window through August 19th 2021<br /> * June 18th 2020<br /> * July 23rd 2020<br /> * August 20th 2020<br /> * September 17th 2020<br /> * October 22nd 2020<br /> * November 19th 2020<br /> * December 17th 2020<br /> * January 21st 2021<br /> * February 18th 2021<br /> * March 25th 2021 (Adjusted date for extended Spring Break)<br /> * April 22nd 2021<br /> * May 20th 2021<br /> * June 17th 2021<br /> * July 22nd 2021<br /> * August 19th 2021<br /> * September 23rd 2021 - BEGIN time of 5pm-8pm for this window and all others below<br /> * October 21st 2021<br /> * November 18th 2021<br /> * January 20th 2022<br /> * February 17th 2022<br /> * March 24th 2022 (Adjusted date for Spring Break)<br /> * April 21st 2022<br /> * May 19th 2022<br /> * June 23rd 2022<br /> * July 21st 2022<br /> * August 18th 2022<br /> * September 22nd 2022<br /> * October 20th 2022<br /> * November 17th 2022<br /> * January 19th 2023<br /> * February 23rd 2023<br /> * April 20th 2023<br /> * May 18th 2023<br /> * June 22nd 2023<br /> * July 20th 2023<br /> * August 17th 2023<br /> * September 21st 2023<br /> * October 19th 2023<br /> * December 20th 2023 (Adjusted date for early Winter Break)<br /> * January 18th 2024<br /> * February 22nd 2024<br /> * March 21st 2024<br /> * April 18th 2024<br /> * May 23th 2024<br /> * June 20th 2024<br /> * July 18th 2024<br /> * August 22nd 2024<br /> * September 19th 2024<br /> * October 17th 2024<br /> * November 21st 2024<br /> * December 19th 2024<br /> * January 23rd 2025<br /> * February 20th 2025<br /> * March 20th 2025<br /> * April 17th 2025<br /> * May 22nd 2025<br /> * June 19th 2025<br /> * July 17th 2025<br /> * August 21st 2025<br /> * September 18th 2025<br /> * October 23rd 2025<br /> * November 20th 2025<br /> * December 18th 2025<br /> * January 22nd 2026<br /> * February 19th 2026<br /> * March 19th 2026<br /> * April 23rd 2026<br /> * May 28th 2026 (Adjusted date for CIO-imposed network change freeze)<br /> * June 18th 2026<br /> * July 23rd 2026<br /> * August 20th 2026<br /> * September 17th 2026</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=WindowsServicing&diff=13395 2026-09-16T18:06:22Z

<p>Mbaney: /* Updating */</p> <hr /> <div>[[Windows]] periodically releases &quot;feature updates&quot; that are designed to bring a large set of new features to all machines that can run Windows. They are typically released annually by Microsoft.<br /> <br /> At UMIACS, we release these feature updates to be installed on all UMIACS-supported Windows desktops as well as Enterprise supported laptops and home machines via our [[Windows Patch Management]]. We typically release feature updates to be installed several months after Microsoft releases them to the general public to ensure that the targeted release is compatible with all software that we run.<br /> <br /> ==Current Feature Updates at UMIACS==<br /> The current feature updates we deploy at UMIACS are:<br /> <br /> {| class=&quot;wikitable&quot;<br /> !OS Version<br /> !Feature Update<br /> |-<br /> |Windows 11<br /> |25H2<br /> |}<br /> <br /> We deployed the current Windows 11 feature update on April 15th, 2026. For a comprehensive list of what is new in this feature update, please see Microsoft's documentation:<br /> * 11: https://learn.microsoft.com/en-us/windows/whats-new/whats-new-windows-11-version-25h2<br /> <br /> '''Windows 10 reached end of support on October 14th, 2025.''' If you still have a university-owned computer running Windows 10, please upgrade it to Windows 11 ASAP. Please [[HelpDesk | contact staff]] if help is needed.<br /> <br /> ==Updating==<br /> 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.<br /> <br /> 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:<br /> <br /> [[File:Windows_Feature_Update.jpg|600px]]</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=File:Windows_Feature_Update.jpg&diff=13394 2026-09-16T18:04:48Z

<p>Mbaney: </p> <hr /> <div></div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=Orders&diff=13393 2026-09-11T15:39:29Z

<p>Mbaney: </p> <hr /> <div>The following pages outline the procedures and best practices for creating and requesting orders.<br /> <br /> =Requesting UMIACS Orders=<br /> &lt;span style=&quot;font-size:150%&quot;&gt;'''Before proceeding''': If the Driver Worktag / KFS account you plan on charging is owned by the Computer Science Department, please instead [https://helpdesk.cs.umd.edu/faq/iribe/equipment-peripherals consult their FAQ] for ordering the equipment you want.&lt;/span&gt;<br /> <br /> ==Important Considerations==<br /> * Verbosity is always preferred to lack of critical details. <br /> * Ticket descriptions should contain a list of specific items being ordered (provide direct links) unless you're attaching an official quote. Please do not include wishlists or links to carts.<br /> * If priority shipping is required, please include that in the &lt;b&gt;subject&lt;/b&gt; of the email.<br /> <br /> ==Option 1: Using the web form==<br /> Fill out the form [https://businessoffice.umiacs.umd.edu/form/order here] and click Submit. This will automatically generate a ticket for staff to action on.<br /> <br /> Please note that you need to be connected to either the ''wired campus network'' or the ''[https://terpware.umd.edu/Windows/Title/4010 campus VPN]'' to access this form.<br /> <br /> ==Option 2: Sending email to staff directly==<br /> &lt;strong&gt;We offer a simple [[Media:Ordering_Form.pdf|Form]] that you can fill out and send to orders@umiacs.umd.edu along with any applicable quote(s).&lt;/strong&gt; Please make sure that you CC the PI or include the email confirmation for any accounts that require committee approval (e.g., RQS).<br /> <br /> Otherwise, please follow these instructions.<br /> <br /> * Please CC the PI for the Driver Worktag / KFS account you want to charge.<br /> * &lt;b&gt;In the body of your email:&lt;/b&gt;<br /> ** Specify the Driver Worktag / KFS account to charge.<br /> ** Specify the items using links or attached quotes and specify the amount of each item. '''Please do not use wishlists or carts.'''<br /> *** Quotes must include any applicable shipping costs.<br /> *** If ordering from numerous vendors:<br /> **** Send one email per vendor. Otherwise, UMIACS staff will separate your request into different emails/[[Jira]] tickets after the fact.<br /> **** 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.<br /> ** 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.<br /> <br /> ==Option 3: Submitting order within [[Jira]] yourself==<br /> Log into the [[Jira]] web interface at https://intranet.umiacs.umd.edu/jira/servicedesk/customer/portals and select the UMIACS Orders option.<br /> <br /> You will be presented with the default ordering screen. Here is a very fictitious example:&lt;br/&gt;<br /> Please note that Summary, Reporter, Account and PI are mandatory fields.&lt;br/&gt;<br /> [[File:ORDERS_main_new.png|465px|600px|alt=Screenshot of an example of Jira of a default ordering screen with all the required information filled out]]<br /> <br /> * &lt;b&gt;Requester&lt;/b&gt; <br /> ** If the order is being requested by CBCB, IMD, MC2, QuICS, or RQS, prepend the summary with [CBCB], [IMD], [MC2], [QuICS], or [RQS] respectively.<br /> * &lt;b&gt;Summary&lt;/b&gt; <br /> ** This should be of the format &quot;&lt;tt&gt;Vendor | Brief Description&lt;/tt&gt;&quot;.<br /> ** If the order &lt;b&gt;must&lt;/b&gt; be placed today, this will instead be &quot;&lt;tt&gt;PRIORITY TODAY | Vendor | Brief Description&lt;/tt&gt;&quot;.<br /> * &lt;b&gt;Account&lt;/b&gt; <br /> ** This should be the Driver Worktag / KFS account to be charged. Please be as specific as possible. Account number is preferred, but if you don't know it, a specific description is OK (e.g., don't say &quot;DRIF&quot; since there are multiple DRIF accounts, instead say &quot;UMIACS DRIF&quot;, or &quot;CBCB DRIF&quot;, etc.)<br /> ** In the event that a single order has multiple accounts, list them all and specify which items are being charged to what accounts (or what percent of an item is being charged to an account) in the description. <br /> * &lt;b&gt;PI&lt;/b&gt;<br /> ** A PI (Principal Adviser) who has approved the purchase on the Driver Worktag / KFS account. <br /> ** In some cases, multiple PIs can charge to a single Driver Worktag / KFS account.<br /> * &lt;b&gt;Description&lt;/b&gt;<br /> ** Provide a description of what you want to buy or provide it in a comment before you submit your order.<br /> ** Provide the purpose of the purchase. If on sponsored funds such as federal grants, the description should also provide how the purchase relates to the purpose of the project.<br /> ** When possible, provide a link to the item to be purchased.<br /> ** When purchasing through Amazon or a site that provides fulfillment for third party vendors, please state the specific vendor that is providing the item and at what price. This is to prevent errors caused by ordering from a different vendor when the site auto-updates.<br /> ** It's good to be polite with your description. ex - &lt;tt&gt;&quot;Hi, please purchase $requestedItems. Here are the links/relevant information: $relevantInformation. Thanks!&quot;&lt;/tt&gt;<br /> <br /> =When Staff Receives the Order=<br /> * As long as the PI is CC'd and all needed information is present, we will go ahead and process the order.<br /> * You will receive an email to pick up the order(s) when it arrives.<br /> ** '''If you are sending someone other than yourself, the PI, or someone already CC'd on the ORDERS ticket to pickup the items''': Please let us know who that person is prior to having them arrive for pickup. Otherwise, we may attempt to contact you at time of pickup to verify their identity/association with the order.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=Nexus/ClusterOSUpgrade&diff=13392 2026-09-09T15:41:27Z

<p>Mbaney: </p> <hr /> <div>==Overview==<br /> 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.<br /> <br /> [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.<br /> <br /> ==Scheduling==<br /> '''Upgrades for all cluster nodes have finished as of Thursday 08/06/2026.'''<br /> <br /> ==Interoperability==<br /> ===Software and Modules===<br /> Please transition your [[PythonVirtualEnv | virtual environments]], workflows, etc. to work with RHEL9 as soon as possible. You can use the submission nodes that you have access to for transitioning and light testing - as always, [[Nexus/Submission_Node_Policy | please do not run any computationally intensive processes on these nodes]]. They are intended to be hosts for configuring environments/workflows and submitting jobs only. If you need to do more involved testing, please schedule a job for this.<br /> <br /> The [[Modules | module tree]] for RHEL9 is populated with a large number of the same modules that are available in the RHEL8 module tree, although specific modules may have different versions available in the RHEL9 tree as compared to the RHEL8 tree. If you have a dependency on a specific version of a module that is not available in the RHEL9 tree, please [[HelpDesk | contact staff]] and we can get one created.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=CyberRange&diff=13391 2026-09-02T21:03:52Z

<p>Mbaney: </p> <hr /> <div>To limit access for a set of resources in UMIACS, we may protect the resources with a cyber range consisting of one or more internal networks.<br /> <br /> This is achieved by using bridge hosts - host(s) for each cyber range that can be used to access the networks, and thus devices, within that cyber range. Devices within a given cyber range do not have direct network access to outside that cyber range. All data transfer for a given cyber range must be staged through the bridge host for that cyber range. <br /> <br /> No computational intensive activities are to be executed on the bridge hosts. Processes will be killed as need be to maintain the availability and access of all cyber ranges.<br /> <br /> There is no limit to the number of networks that can be associated with a given cyber range. One secondary network that many cyber ranges may have is one to access out-of-band management devices such as [https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface baseboard management controllers (BMCs) through IPMI] for bare metal servers in the range.<br /> <br /> =Access=<br /> To access cyber range bridge hosts in UMIACS, you must be connected to either the UMIACS wired network or [[VPN | UMD's GlobalProtect VPN]].<br /> <br /> After connecting, you can SSH to the bridge host for a cyber range (eg. &lt;code&gt;ssh username@bridge_host.umiacs.umd.edu&lt;/code&gt;) and provide your credentials and MFA to connect. Once you are connected, you can now jump to any internal host in that cyber range over SSH. If you need to access a graphical interface, see the [[#Remote Desktop Access | Remote Desktop Access]] section below.<br /> <br /> If you need to stage data onto a device within a cyber range, you can use the bridge host for that cyber range as a [[SSH_Jumphosts | SSH jump host]]. Here are some examples using &lt;code&gt;scp&lt;/code&gt; or &lt;code&gt;rsync&lt;/code&gt;.<br /> <br /> * &lt;code&gt;scp -J user@bridge_host /path/to/local/file user@target_server:/path/to/destination/&lt;/code&gt;<br /> * &lt;code&gt;rsync -avz -e &quot;ssh -J user@bridge_host&quot; /path/to/local/folder/ user@target_server:/path/to/destination/&lt;/code&gt;<br /> <br /> =Temporary Storage=<br /> If data needs to be temporarily stored on the bridge host for a cyber range, it can be stored in &lt;code&gt;/scratch0&lt;/code&gt;. [[FilesystemDataStorage#UNIX_Filesystem_Storage | This directory is not backed up and should not be used to hold primary copies of any data that is critical.]] If the scratch space on a bridge host becomes full, the Technical Staff reserve the right to clear out the space as necessary to support the activities of the cyber range. <br /> <br /> =Network Services=<br /> Network services like DNS and DHCP are provided by each cyber range's bridge host to that internal cyber range's networks.<br /> <br /> =Remote Desktop Access=<br /> Bridge hosts provide [[Remote Desktop]] access locally that can be used with a simple SSH port forwarding tunnel. In a local terminal window, you can run the following command to start this tunnel, providing your credentials and MFA.<br /> <br /> &lt;code&gt;ssh -L 33389:localhost:3389 username@bridge_host.umiacs.umd.edu&lt;/code&gt;<br /> <br /> You can then use your local RDP client to connect to &lt;code&gt;bridge_host.umiacs.umd.edu:33389&lt;/code&gt; and you will be logged into a console session on the bridge host. You can disconnect and re-connect to the console.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=CyberRange&diff=13390 2026-09-02T21:02:46Z

<p>Mbaney: </p> <hr /> <div>To limit access for a set of resources in UMIACS, we may protect the resources with a cyber range consisting of one or more internal networks.<br /> <br /> This is achieved by using bridge hosts - host(s) for each cyber range that can be used to access the networks, and thus devices, within that cyber range. Devices within a given cyber range do not have direct network access to outside that cyber range. All data transfer for a given cyber range must be staged through the bridge host for that cyber range. <br /> <br /> No computational intensive activities are to be executed on the bridge hosts. Processes will be killed as need be to maintain the availability and access of all cyber ranges.<br /> <br /> There is no limit to the number of networks that can be associated with a given cyber range. One secondary network that many cyber ranges may have is one to access out-of-band management devices such as [https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface baseboard management controllers (BMCs) through IPMI] for bare metal servers in the range.<br /> <br /> =Access=<br /> To access cyber range bridge hosts in UMIACS, you must be connected to either the UMIACS wired network or [[VPN | UMD's GlobalProtect VPN]].<br /> <br /> After connecting, you can SSH to the bridge host for a cyber range (eg. &lt;code&gt;ssh username@bridge_host.umiacs.umd.edu&lt;/code&gt;) and provide your credentials and MFA to connect. Once you are connected, you can now jump to any internal host in that cyber range over SSH. If you need to access a graphical interface, see the [[#Remote Desktop Access | Remote Desktop Access]] section below.<br /> <br /> If you need to stage data onto a device within a cyber range, you can use the bridge host for that cyber range as a [[SSH_Jumphosts | SSH jump host]]. Here are some examples using &lt;code&gt;scp&lt;/code&gt; or &lt;code&gt;rsync&lt;/code&gt;.<br /> <br /> * &lt;code&gt;scp -J user@bridge_host /path/to/local/file user@target_server:/path/to/destination/&lt;/code&gt;<br /> * &lt;code&gt;rsync -avz -e &quot;ssh -J user@bridge_host&quot; /path/to/local/folder/ user@target_server:/path/to/destination/&lt;/code&gt;<br /> <br /> =Temporary Storage=<br /> If data needs to be temporarily stored on the bridge host for a cyber range, it can be stored in &lt;code&gt;/scratch0&lt;/code&gt;. [[FilesystemDataStorage#UNIX_Filesystem_Storage | This directory is not backed up and should not be used to hold primary copies of any data that is critical.]] If the scratch space on a bridge host becomes full, the Technical Staff reserve the right to clear out the space as necessary to support the activities of the cyber range. <br /> <br /> =Network Services=<br /> Network services like DNS and DHCP are provided by each cyber range's bridge host to that internal cyber range's networks.<br /> <br /> =Remote Desktop Access=<br /> Bridge host(s) provide [[Remote Desktop]] access locally that can be used with a simple SSH port forwarding tunnel. In a local terminal window, you can run the following command providing your credentials and MFA.<br /> <br /> &lt;code&gt;ssh -L 33389:localhost:3389 username@bridge_host.umiacs.umd.edu&lt;/code&gt;<br /> <br /> You can then use your local RDP client to connect to &lt;code&gt;bridge_host.umiacs.umd.edu:33389&lt;/code&gt; and you will be logged into a console session on the bridge host. You can disconnect and re-connect to the console.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=CyberRange&diff=13389 2026-09-02T21:02:13Z

<p>Mbaney: </p> <hr /> <div>To limit access for a set of resources in UMIACS, we may protect the resources with a cyber range consisting of one or more internal networks.<br /> <br /> This is achieved by using bridge hosts - host(s) for each cyber range that can be used to access the networks, and thus devices, within that cyber range. Devices within a given cyber range do not have direct network access to outside that cyber range. All data transfer for a given cyber range must be staged through the bridge host for that cyber range. <br /> <br /> No computational intensive activities are to be executed on the bridge hosts. Processes will be killed as need be to maintain the availability and access of all cyber ranges.<br /> <br /> There is no limit to the number of networks that can be associated with a given cyber range. One secondary network that many cyber ranges may have is one to access out-of-band management devices such as [https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface baseboard management controllers (BMCs) through IPMI] for bare metal servers in the range.<br /> <br /> =Access=<br /> To access cyber range bridge hosts in UMIACS, you must be connected to either the UMIACS wired network or [[VPN | UMD's GlobalProtect VPN]].<br /> <br /> After connecting, you can SSH to the bridge host for a cyber range (eg. &lt;code&gt;ssh username@bridge_host.umiacs.umd.edu&lt;/code&gt;) and provide your credentials and MFA to connect. Once you are logged in, you can now jump to any internal host in that cyber range over SSH. If you need to access a graphical interface, see the [[#Remote Desktop Access | Remote Desktop Access]] section below.<br /> <br /> If you need to stage data onto a device within a cyber range, you can use the bridge host for that cyber range as a [[SSH_Jumphosts | SSH jump host]]. Here are some examples using &lt;code&gt;scp&lt;/code&gt; or &lt;code&gt;rsync&lt;/code&gt;.<br /> <br /> * &lt;code&gt;scp -J user@bridge_host /path/to/local/file user@target_server:/path/to/destination/&lt;/code&gt;<br /> * &lt;code&gt;rsync -avz -e &quot;ssh -J user@bridge_host&quot; /path/to/local/folder/ user@target_server:/path/to/destination/&lt;/code&gt;<br /> <br /> =Temporary Storage=<br /> If data needs to be temporarily stored on the bridge host for a cyber range, it can be stored in &lt;code&gt;/scratch0&lt;/code&gt;. [[FilesystemDataStorage#UNIX_Filesystem_Storage | This directory is not backed up and should not be used to hold primary copies of any data that is critical.]] If the scratch space on a bridge host becomes full, the Technical Staff reserve the right to clear out the space as necessary to support the activities of the cyber range. <br /> <br /> =Network Services=<br /> Network services like DNS and DHCP are provided by each cyber range's bridge host to that internal cyber range's networks.<br /> <br /> =Remote Desktop Access=<br /> Bridge host(s) provide [[Remote Desktop]] access locally that can be used with a simple SSH port forwarding tunnel. In a local terminal window, you can run the following command providing your credentials and MFA.<br /> <br /> &lt;code&gt;ssh -L 33389:localhost:3389 username@bridge_host.umiacs.umd.edu&lt;/code&gt;<br /> <br /> You can then use your local RDP client to connect to &lt;code&gt;bridge_host.umiacs.umd.edu:33389&lt;/code&gt; and you will be logged into a console session on the bridge host. You can disconnect and re-connect to the console.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=CyberRange&diff=13388 2026-09-02T21:01:33Z

<p>Mbaney: </p> <hr /> <div>To limit access for a set of resources in UMIACS, we may protect the resources with a cyber range consisting of one or more internal networks.<br /> <br /> This is achieved by using bridge hosts - host(s) for each cyber range that can be used to access the networks, and thus devices, within that cyber range. Devices within a given cyber range do not have direct network access to outside that cyber range. All data transfer for a given cyber range must be staged through the bridge host for that cyber range. <br /> <br /> No computational intensive activities are to be executed on the bridge hosts. Processes will be killed as need be to maintain the availability and access of all cyber ranges.<br /> <br /> There is no limit to the number of networks that can be associated with a given cyber range. One secondary network that many cyber ranges may have is one to access out-of-band management devices such as [https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface baseboard management controllers (BMCs)] for bare metal servers in the range.<br /> <br /> =Access=<br /> To access cyber range bridge hosts in UMIACS, you must be connected to either the UMIACS wired network or [[VPN | UMD's GlobalProtect VPN]].<br /> <br /> After connecting, you can SSH to the bridge host for a cyber range (eg. &lt;code&gt;ssh username@bridge_host.umiacs.umd.edu&lt;/code&gt;) and provide your credentials and MFA to connect. Once you are logged in, you can now jump to any internal host in that cyber range over SSH. If you need to access a graphical interface, see the [[#Remote Desktop Access | Remote Desktop Access]] section below.<br /> <br /> If you need to stage data onto a device within a cyber range, you can use the bridge host for that cyber range as a [[SSH_Jumphosts | SSH jump host]]. Here are some examples using &lt;code&gt;scp&lt;/code&gt; or &lt;code&gt;rsync&lt;/code&gt;.<br /> <br /> * &lt;code&gt;scp -J user@bridge_host /path/to/local/file user@target_server:/path/to/destination/&lt;/code&gt;<br /> * &lt;code&gt;rsync -avz -e &quot;ssh -J user@bridge_host&quot; /path/to/local/folder/ user@target_server:/path/to/destination/&lt;/code&gt;<br /> <br /> =Temporary Storage=<br /> If data needs to be temporarily stored on the bridge host for a cyber range, it can be stored in &lt;code&gt;/scratch0&lt;/code&gt;. [[FilesystemDataStorage#UNIX_Filesystem_Storage | This directory is not backed up and should not be used to hold primary copies of any data that is critical.]] If the scratch space on a bridge host becomes full, the Technical Staff reserve the right to clear out the space as necessary to support the activities of the cyber range. <br /> <br /> =Network Services=<br /> Network services like DNS and DHCP are provided by each cyber range's bridge host to that internal cyber range's networks.<br /> <br /> =Remote Desktop Access=<br /> Bridge host(s) provide [[Remote Desktop]] access locally that can be used with a simple SSH port forwarding tunnel. In a local terminal window, you can run the following command providing your credentials and MFA.<br /> <br /> &lt;code&gt;ssh -L 33389:localhost:3389 username@bridge_host.umiacs.umd.edu&lt;/code&gt;<br /> <br /> You can then use your local RDP client to connect to &lt;code&gt;bridge_host.umiacs.umd.edu:33389&lt;/code&gt; and you will be logged into a console session on the bridge host. You can disconnect and re-connect to the console.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=CyberRange&diff=13387 2026-09-02T21:00:53Z

<p>Mbaney: </p> <hr /> <div>To limit access for a set of resources in UMIACS, we may protect the resources with a cyber range consisting of one or more internal networks.<br /> <br /> This is achieved by using bridge hosts - host(s) for each cyber range that can be used to access the networks, and thus devices, within that cyber range. Devices within a given cyber range do not have direct network access to outside that cyber range. All data transfer for a given cyber range must be staged through the bridge host for that cyber range. <br /> <br /> No computational intensive activities are to be executed on the bridge hosts. Processes will be killed as need be to maintain the availability and access of all cyber ranges.<br /> <br /> There is no limit to the number of networks that can be associated with a given cyber range. One secondary network that many cyber ranges may have is one to access out-of-band management devices such as baseboard management controllers (BMCs) for bare metal servers in the range.<br /> <br /> =Access=<br /> To access cyber range bridge hosts in UMIACS, you must be connected to either the UMIACS wired network or [[VPN | UMD's GlobalProtect VPN]].<br /> <br /> After connecting, you can SSH to the bridge host for a cyber range (eg. &lt;code&gt;ssh username@bridge_host.umiacs.umd.edu&lt;/code&gt;) and provide your credentials and MFA to connect. Once you are logged in, you can now jump to any internal host in that cyber range over SSH. If you need to access a graphical interface, see the [[#Remote Desktop Access | Remote Desktop Access]] section below.<br /> <br /> If you need to stage data onto a device within a cyber range, you can use the bridge host for that cyber range as a [[SSH_Jumphosts | SSH jump host]]. Here are some examples using &lt;code&gt;scp&lt;/code&gt; or &lt;code&gt;rsync&lt;/code&gt;.<br /> <br /> * &lt;code&gt;scp -J user@bridge_host /path/to/local/file user@target_server:/path/to/destination/&lt;/code&gt;<br /> * &lt;code&gt;rsync -avz -e &quot;ssh -J user@bridge_host&quot; /path/to/local/folder/ user@target_server:/path/to/destination/&lt;/code&gt;<br /> <br /> =Temporary Storage=<br /> If data needs to be temporarily stored on the bridge host for a cyber range, it can be stored in &lt;code&gt;/scratch0&lt;/code&gt;. [[FilesystemDataStorage#UNIX_Filesystem_Storage | This directory is not backed up and should not be used to hold primary copies of any data that is critical.]] If the scratch space on a bridge host becomes full, the Technical Staff reserve the right to clear out the space as necessary to support the activities of the cyber range. <br /> <br /> =Network Services=<br /> Network services like DNS and DHCP are provided by each cyber range's bridge host to that internal cyber range's networks.<br /> <br /> =Remote Desktop Access=<br /> Bridge host(s) provide [[Remote Desktop]] access locally that can be used with a simple SSH port forwarding tunnel. In a local terminal window, you can run the following command providing your credentials and MFA.<br /> <br /> &lt;code&gt;ssh -L 33389:localhost:3389 username@bridge_host.umiacs.umd.edu&lt;/code&gt;<br /> <br /> You can then use your local RDP client to connect to &lt;code&gt;bridge_host.umiacs.umd.edu:33389&lt;/code&gt; and you will be logged into a console session on the bridge host. You can disconnect and re-connect to the console.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=CyberRange&diff=13386 2026-09-02T21:00:39Z

<p>Mbaney: </p> <hr /> <div>To limit access for a set of resources in UMIACS, we may protect the resources with a cyber range consisting of one or more internal networks.<br /> <br /> This is achieved by using bridge hosts - host(s) for each cyber range that can be used to access the networks, and thus devices, within that cyber range. Devices within a given cyber range do not have direct network access to outside that cyber range. All data transfer for a given cyber range must be staged through the bridge host for that cyber range. <br /> <br /> No computational intensive activities are to be executed on the bridge hosts. Processes will be killed as need be to maintain the availability and access of all cyber ranges.<br /> <br /> There is no limit to the number of networks that can be associated with a given cyber range. One common secondary network that many cyber ranges may have is one to access out-of-band management devices such as baseboard management controllers (BMCs) for bare metal servers in the range.<br /> <br /> =Access=<br /> To access cyber range bridge hosts in UMIACS, you must be connected to either the UMIACS wired network or [[VPN | UMD's GlobalProtect VPN]].<br /> <br /> After connecting, you can SSH to the bridge host for a cyber range (eg. &lt;code&gt;ssh username@bridge_host.umiacs.umd.edu&lt;/code&gt;) and provide your credentials and MFA to connect. Once you are logged in, you can now jump to any internal host in that cyber range over SSH. If you need to access a graphical interface, see the [[#Remote Desktop Access | Remote Desktop Access]] section below.<br /> <br /> If you need to stage data onto a device within a cyber range, you can use the bridge host for that cyber range as a [[SSH_Jumphosts | SSH jump host]]. Here are some examples using &lt;code&gt;scp&lt;/code&gt; or &lt;code&gt;rsync&lt;/code&gt;.<br /> <br /> * &lt;code&gt;scp -J user@bridge_host /path/to/local/file user@target_server:/path/to/destination/&lt;/code&gt;<br /> * &lt;code&gt;rsync -avz -e &quot;ssh -J user@bridge_host&quot; /path/to/local/folder/ user@target_server:/path/to/destination/&lt;/code&gt;<br /> <br /> =Temporary Storage=<br /> If data needs to be temporarily stored on the bridge host for a cyber range, it can be stored in &lt;code&gt;/scratch0&lt;/code&gt;. [[FilesystemDataStorage#UNIX_Filesystem_Storage | This directory is not backed up and should not be used to hold primary copies of any data that is critical.]] If the scratch space on a bridge host becomes full, the Technical Staff reserve the right to clear out the space as necessary to support the activities of the cyber range. <br /> <br /> =Network Services=<br /> Network services like DNS and DHCP are provided by each cyber range's bridge host to that internal cyber range's networks.<br /> <br /> =Remote Desktop Access=<br /> Bridge host(s) provide [[Remote Desktop]] access locally that can be used with a simple SSH port forwarding tunnel. In a local terminal window, you can run the following command providing your credentials and MFA.<br /> <br /> &lt;code&gt;ssh -L 33389:localhost:3389 username@bridge_host.umiacs.umd.edu&lt;/code&gt;<br /> <br /> You can then use your local RDP client to connect to &lt;code&gt;bridge_host.umiacs.umd.edu:33389&lt;/code&gt; and you will be logged into a console session on the bridge host. You can disconnect and re-connect to the console.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=CyberRange&diff=13385 2026-09-02T20:59:00Z

<p>Mbaney: </p> <hr /> <div>To limit access for a set of resources in UMIACS, we may protect the resources with a cyber range consisting of one or more internal networks.<br /> <br /> This is achieved by using a bridge host for each cyber range that can be used to access the networks, and thus devices, within that cyber range. Devices within a given cyber range do not have direct network access to outside that cyber range. There is no limit to the number of networks that can be associated with a given cyber range. One common secondary network that many cyber ranges may have is one to access out-of-band management devices such as baseboard management controllers (BMCs) for bare metal servers in the range. All data transfer for a given cyber range must be staged through the bridge host for that cyber range.<br /> <br /> No computational intensive activities are to be executed on the bridge hosts. Processes will be killed as need be to maintain the availability and access of all cyber ranges.<br /> <br /> =Access=<br /> To access cyber range bridge hosts in UMIACS, you must be connected to either the UMIACS wired network or [[VPN | UMD's GlobalProtect VPN]].<br /> <br /> After connecting, you can SSH to the bridge host for a cyber range (eg. &lt;code&gt;ssh username@bridge_host.umiacs.umd.edu&lt;/code&gt;) and provide your credentials and MFA to connect. Once you are logged in, you can now jump to any internal host in that cyber range over SSH. If you need to access a graphical interface, see the [[#Remote Desktop Access | Remote Desktop Access]] section below.<br /> <br /> If you need to stage data onto a device within a cyber range, you can use the bridge host for that cyber range as a [[SSH_Jumphosts | SSH jump host]]. Here are some examples using &lt;code&gt;scp&lt;/code&gt; or &lt;code&gt;rsync&lt;/code&gt;.<br /> <br /> * &lt;code&gt;scp -J user@bridge_host /path/to/local/file user@target_server:/path/to/destination/&lt;/code&gt;<br /> * &lt;code&gt;rsync -avz -e &quot;ssh -J user@bridge_host&quot; /path/to/local/folder/ user@target_server:/path/to/destination/&lt;/code&gt;<br /> <br /> =Temporary Storage=<br /> If data needs to be temporarily stored on the bridge host for a cyber range, it can be stored in &lt;code&gt;/scratch0&lt;/code&gt;. [[FilesystemDataStorage#UNIX_Filesystem_Storage | This directory is not backed up and should not be used to hold primary copies of any data that is critical.]] If the scratch space on a bridge host becomes full, the Technical Staff reserve the right to clear out the space as necessary to support the activities of the cyber range. <br /> <br /> =Network Services=<br /> Network services like DNS and DHCP are provided by each cyber range's bridge host to that internal cyber range's networks.<br /> <br /> =Remote Desktop Access=<br /> Bridge host(s) provide [[Remote Desktop]] access locally that can be used with a simple SSH port forwarding tunnel. In a local terminal window, you can run the following command providing your credentials and MFA.<br /> <br /> &lt;code&gt;ssh -L 33389:localhost:3389 username@bridge_host.umiacs.umd.edu&lt;/code&gt;<br /> <br /> You can then use your local RDP client to connect to &lt;code&gt;bridge_host.umiacs.umd.edu:33389&lt;/code&gt; and you will be logged into a console session on the bridge host. You can disconnect and re-connect to the console.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=CyberRange&diff=13384 2026-09-02T20:53:56Z

<p>Mbaney: </p> <hr /> <div>To limit access for a set of resources in UMIACS, we may protect the networks with a cyber range.<br /> <br /> This is achieved by using a bridge host for each cyber range that can be used to access the devices within that cyber range. The devices within a given cyber range can have multiple networks associated with them, including a network that provides access to out-of-band management devices such as baseboard management controllers (BMCs). Devices within a given cyber range do not have direct network access to outside that cyber range. All data transfer for a given cyber range must be staged through the bridge host for that cyber range.<br /> <br /> No computational intensive activities are to be executed on the bridge hosts. Processes will be killed as need be to maintain the availability and access of all cyber ranges.<br /> <br /> =Access=<br /> To access cyber range bridge hosts in UMIACS, you must be connected to either the UMIACS wired network or [[VPN | UMD's GlobalProtect VPN]].<br /> <br /> After connecting, you can SSH to the bridge host for a cyber range (eg. &lt;code&gt;ssh username@bridge_host.umiacs.umd.edu&lt;/code&gt;) and provide your credentials and MFA to connect. Once you are logged in, you can now jump to any internal host in that cyber range over SSH. If you need to access a graphical interface, see the [[#Remote Desktop Access | Remote Desktop Access]] section below.<br /> <br /> If you need to stage data onto a device within a cyber range, you can use the bridge host for that cyber range as a [[SSH_Jumphosts | SSH jump host]]. Here are some examples using &lt;code&gt;scp&lt;/code&gt; or &lt;code&gt;rsync&lt;/code&gt;.<br /> <br /> * &lt;code&gt;scp -J user@bridge_host /path/to/local/file user@target_server:/path/to/destination/&lt;/code&gt;<br /> * &lt;code&gt;rsync -avz -e &quot;ssh -J user@bridge_host&quot; /path/to/local/folder/ user@target_server:/path/to/destination/&lt;/code&gt;<br /> <br /> =Temporary Storage=<br /> If data needs to be temporarily stored on the bridge host for a cyber range, it can be stored in &lt;code&gt;/scratch0&lt;/code&gt;. [[FilesystemDataStorage#UNIX_Filesystem_Storage | This directory is not backed up and should not be used to hold primary copies of any data that is critical.]] If the scratch space on a bridge host becomes full, the Technical Staff reserve the right to clear out the space as necessary to support the activities of the cyber range. <br /> <br /> =Network Services=<br /> Network services like DNS and DHCP are provided by each cyber range's bridge host to that internal cyber range's networks.<br /> <br /> =Remote Desktop Access=<br /> Bridge host(s) provide [[Remote Desktop]] access locally that can be used with a simple SSH port forwarding tunnel. In a local terminal window, you can run the following command providing your credentials and MFA.<br /> <br /> &lt;code&gt;ssh -L 33389:localhost:3389 username@bridge_host.umiacs.umd.edu&lt;/code&gt;<br /> <br /> You can then use your local RDP client to connect to &lt;code&gt;bridge_host.umiacs.umd.edu:33389&lt;/code&gt; and you will be logged into a console session on the bridge host. You can disconnect and re-connect to the console.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=CyberRange&diff=13383 2026-09-02T20:49:45Z

<p>Mbaney: </p> <hr /> <div>To limit access for a set of resources in UMIACS, we may protect the networks with a cyber range.<br /> <br /> This is achieved by using a bridge host for each cyber range that can be used to access the devices within that cyber range. The devices within a given cyber range can have multiple networks associated with them, including a network that provides access to out-of-band management devices such as baseboard management controllers (BMCs). Devices within a given cyber range do not have direct network access to outside that cyber range. All data transfer for a given cyber range must be staged through the bridge host for that cyber range.<br /> <br /> No computational intensive activities are to be executed on the bridge hosts. Processes will be killed as need be to maintain the availability and access of all cyber ranges.<br /> <br /> =Access=<br /> To access cyber range bridge hosts in UMIACS, you first need to be connected to the UMIACS network or [[VPN | UMD's GlobalProtect VPN]].<br /> <br /> After connecting, you can SSH to the bridge host for a cyber range (eg. &lt;code&gt;ssh username@bridge_host.umiacs.umd.edu&lt;/code&gt;) and provide your credentials and MFA to connect. Once you are logged in, you can now jump to any internal host in that cyber range over SSH. If you need to access a graphical interface, see the [[#Remote Desktop Access | Remote Desktop Access]] section below.<br /> <br /> If you need to stage data, you can use the bridge host as a [[SSH_Jumphosts | SSH jump host]]. Here are some examples using &lt;code&gt;scp&lt;/code&gt; or &lt;code&gt;rsync&lt;/code&gt;.<br /> <br /> * &lt;code&gt;scp -J user@bridge_host /path/to/local/file user@target_server:/path/to/destination/&lt;/code&gt;<br /> * &lt;code&gt;rsync -avz -e &quot;ssh -J user@bridge_host&quot; /path/to/local/folder/ user@target_server:/path/to/destination/&lt;/code&gt;<br /> <br /> =Temporary Storage=<br /> If data needs to be temporarily stored on the bridge host, it can be stored in &lt;code&gt;/scratch0&lt;/code&gt;. [[FilesystemDataStorage#UNIX_Filesystem_Storage | This directory is not backed up and should not be used to hold primary copies of any data that is critical.]] If the scratch space on a bridge host becomes full, the Technical Staff reserve the right to clear out the space as necessary to support the activities of the cyber range. <br /> <br /> =Network Services=<br /> Network services like DNS and DHCP are provided by each cyber range's bridge host to that internal cyber range's networks.<br /> <br /> =Remote Desktop Access=<br /> Bridge host(s) provide remote desktop access locally that can be used with a simple SSH port forwarding tunnel. In a local terminal window, you can run the following command providing your credentials and MFA.<br /> <br /> &lt;code&gt;ssh -L 33389:localhost:3389 username@bridge_host.umiacs.umd.edu&lt;/code&gt;<br /> <br /> You can then use your local RDP client to connect to &lt;code&gt;bridge_host.umiacs.umd.edu:33389&lt;/code&gt; and you will be logged into a console session on the bridge host. You can disconnect and re-connect to the console.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=CyberRange&diff=13382 2026-09-02T20:46:02Z

<p>Mbaney: </p> <hr /> <div>To limit access for a set of resources in UMIACS, we may protect the networks with a cyber range.<br /> <br /> This is achieved by using a bridge host for each cyber range that can be used to access the devices within that cyber range. The devices within a given cyber range can have multiple networks associated with them, including a network that provides access to out-of-band management devices such as baseboard management controllers (BMCs). Devices within a given cyber range do not have direct network access to outside that cyber range. All data transfer for a given cyber range must be staged through the bridge host for that cyber range.<br /> <br /> No computational intensive activities are to be executed on the bridge hosts. Processes will be killed as need be to maintain the availability and access of all cyber ranges.<br /> <br /> =Access=<br /> To access cyber range bridge hosts in UMIACS, you first need to be connected to the UMIACS network or [[VPN | UMD's GlobalProtect VPN]].<br /> <br /> After connecting, you can SSH to the bridge host for a cyber range (eg. &lt;code&gt;ssh username@bridge_host.umiacs.umd.edu&lt;/code&gt;) and provide your credentials and MFA to connect. Once you are logged in, you can now jump to any internal host in that cyber range over SSH. If you need to access a graphical interface, see the Remote Desktop Access section below.<br /> <br /> If you need to stage data, you can use the bridge host as a [[SSH_Jumphosts | SSH jump host]]. Here are some examples using &lt;code&gt;scp&lt;/code&gt; or &lt;code&gt;rsync&lt;/code&gt;.<br /> <br /> * &lt;code&gt;scp -J user@bridge_host /path/to/local/file user@target_server:/path/to/destination/&lt;/code&gt;<br /> * &lt;code&gt;rsync -avz -e &quot;ssh -J user@bridge_host&quot; /path/to/local/folder/ user@target_server:/path/to/destination/&lt;/code&gt;<br /> <br /> =Temporary Storage=<br /> If data needs to be temporarily stored on the bridge host, it can be stored in &lt;code&gt;/scratch0&lt;/code&gt;. [[FilesystemDataStorage#UNIX_Filesystem_Storage | This data is not backed up and should not be used as a primary copy of any data that is critical.]] If the space is fully allocated, the Technical Staff reserve the right to clear out the space as necessary to support the activities of the cyber range. <br /> <br /> =Network Services=<br /> Network services like DNS and DHCP are provided by each cyber range's bridge host to that internal cyber range's networks.<br /> <br /> =Remote Desktop Access=<br /> Bridge host(s) provide remote desktop access locally that can be used with a simple SSH port forwarding tunnel. In a local terminal window, you can run the following command providing your credentials and MFA.<br /> <br /> &lt;code&gt;ssh -L 33389:localhost:3389 username@bridge_host.umiacs.umd.edu&lt;/code&gt;<br /> <br /> You can then use your local RDP client to connect to &lt;code&gt;bridge_host.umiacs.umd.edu:33389&lt;/code&gt; and you will be logged into a console session on the bridge host. You can disconnect and re-connect to the console.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=CyberRange&diff=13381 2026-09-02T20:42:22Z

<p>Mbaney: </p> <hr /> <div>To limit access for a set of resources in UMIACS, we may protect the networks with a cyber range.<br /> <br /> This is achieved by using a bridge host that users can use to access the devices within the cyber range. The devices within the cyber range can have multiple networks including a network that provides access to out of band management devices. Devices within the cyber range do not have direct network access to outside the cyber range. All data transfer for a given cyber range must be staged through the bridge host for that cyber range.<br /> <br /> No computational intensive activities are to be executed on the bridge hosts. Processes will be killed as need be to maintain the availability and access of the cyber range.<br /> <br /> =Access=<br /> To access cyber range bridge hosts in UMIACS, you need to be connected to the UMIACS network or [[VPN | UMD's GlobalProtect VPN]].<br /> <br /> Then you would need to ssh to the bridge host (eg. &lt;code&gt;ssh username@bridge_host.umiacs.umd.edu&lt;/code&gt;) and provide your credentials and MFA to connect. Once you are logged in you can now jump to any internal host in the range over SSH. If you need to access a graphical interface, see the Remote Desktop Access section below.<br /> <br /> If you need to stage data, you can use the bridge host as a [[SSH_Jumphosts | SSH jump host]]. Here are some examples using &lt;code&gt;scp&lt;/code&gt; or &lt;code&gt;rsync&lt;/code&gt;.<br /> <br /> * &lt;code&gt;scp -J user@bridge_host /path/to/local/file user@target_server:/path/to/destination/&lt;/code&gt;<br /> * &lt;code&gt;rsync -avz -e &quot;ssh -J user@bridge_host&quot; /path/to/local/folder/ user@target_server:/path/to/destination/&lt;/code&gt;<br /> <br /> =Temporary Storage=<br /> If data needs to be temporarily stored on the bridge host, it can be stored in &lt;code&gt;/scratch0&lt;/code&gt;. [[FilesystemDataStorage#UNIX_Filesystem_Storage | This data is not backed up and should not be used as a primary copy of any data that is critical.]] If the space is fully allocated, the Technical Staff reserve the right to clear out the space as necessary to support the activities of the cyber range. <br /> <br /> =Network Services=<br /> Network services like DNS and DHCP are provided by the bridge host to the internal cyber range networks.<br /> <br /> =Remote Desktop Access=<br /> Bridge host(s) provide remote desktop access locally that can be used with a simple SSH port forwarding tunnel. In a local terminal window, you can run the following command providing your credentials and MFA.<br /> <br /> &lt;code&gt;ssh -L 33389:localhost:3389 username@bridge_host.umiacs.umd.edu&lt;/code&gt;<br /> <br /> You can then use your local RDP client to connect to &lt;code&gt;bridge_host.umiacs.umd.edu:33389&lt;/code&gt; and you will be logged into a console session on the bridging host. You can disconnect and re-connect to the console.</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=SLURM/JobSubmission&diff=13368 2026-08-28T15:26:13Z

<p>Mbaney: /* Examples */</p> <hr /> <div>=Job Submission=<br /> SLURM offers a variety of ways to run jobs. It is important to understand the different options available and how to request the resources required for a job in order for it to run successfully. All job submission should be done from submit nodes; any computational code should be run in a job allocation on compute nodes. The following commands outline how to allocate resources on the compute nodes and submit processes to be run on the allocated nodes.<br /> <br /> The cluster that everyone with a [[Accounts#UMIACS_Account | UMIACS account]] has access to is [[Nexus]]. Please visit the Nexus page for instructions on how to connect to your assigned submit nodes.<br /> <br /> '''Computationally intensive processes run on submission nodes will be terminated. Please submit jobs to be scheduled on compute nodes for this purpose.'''<br /> <br /> For details on how SLURM decides how to schedule jobs when multiple jobs are waiting in a scheduler's queue, please see [[SLURM/Priority]].<br /> <br /> ==srun==<br /> The &lt;code&gt;srun&lt;/code&gt; command is used to run a process on the compute nodes in the cluster. If you pass it a normal shell command (or command that executes a script), it will submit a job to run that shell command/script on a compute node and then return. &lt;code&gt;srun&lt;/code&gt; accepts many command line options to specify the resources required by the command passed to it. Some common command line arguments are listed below and full documentation of all available options is available in the man page for &lt;code&gt;srun&lt;/code&gt;, which can be accessed by running &lt;code&gt;man srun&lt;/code&gt;.<br /> <br /> &lt;pre&gt;<br /> $ srun --qos=default --mem=100mb --time=1:00:00 bash -c 'echo &quot;Hello World from&quot; `hostname`'<br /> Hello World from tron33.umiacs.umd.edu<br /> &lt;/pre&gt;<br /> <br /> It is important to understand that &lt;code&gt;srun&lt;/code&gt; is an interactive command. By default input to &lt;code&gt;srun&lt;/code&gt; is broadcast to all compute nodes running your process and output from the compute nodes is redirected to &lt;code&gt;srun&lt;/code&gt;. This behavior can be changed; however, '''srun will always wait for the command passed to finish before exiting, so if you start a long running process and end your terminal session, your process will stop running on the compute nodes and your job will end'''. To run a non-interactive submission that will remain running after you logout, you will need to wrap your &lt;code&gt;srun&lt;/code&gt; commands in a batch script and submit it with [[#sbatch | sbatch]].<br /> <br /> ===Common srun Arguments===<br /> * &lt;code&gt;--job-name=&lt;JOBNAME&gt;&lt;/code&gt; ''Requests your job be named &lt;JOBNAME&gt;''<br /> * &lt;code&gt;--mem=1g&lt;/code&gt; ''Requests 1GB of memory for your job, if no unit is given MB is assumed''<br /> * &lt;code&gt;--ntasks=2&lt;/code&gt; ''Requests 2 &quot;tasks&quot; which map to cores on a CPU for your job; if passed to srun, runs the given command concurrently on each core''<br /> * &lt;code&gt;--cpus-per-task=2&lt;/code&gt; ''Requests 2 CPU cores be allocated per task for your job''<br /> * &lt;code&gt;--nodes=2&lt;/code&gt; ''Requests 2 nodes be allocated to your job; if passed to srun, runs the given command concurrently on each node''<br /> * &lt;code&gt;--nodelist=&lt;NODENAME&gt;&lt;/code&gt; ''Requests to run your job on the &lt;NODENAME&gt; node''<br /> * &lt;code&gt;--time=dd-hh:mm:ss&lt;/code&gt; ''Requests your job run for dd days, hh hours, mm minutes, and ss seconds''<br /> * &lt;code&gt;--error=&lt;ERRNAME&gt;&lt;/code&gt; ''Redirects stderr for your job to the &lt;ERRNAME&gt; file''<br /> * &lt;code&gt;--partition=&lt;PARTITIONNAME&gt;&lt;/code&gt; ''Requests your job run in the &lt;PARTITIONNAME&gt; partition''<br /> * &lt;code&gt;--qos=&lt;QOSNAME&gt;default&lt;/code&gt; ''Requests your job run with the &lt;QOSNAME&gt; QOS, to see the available QOS options on a cluster, run'' &lt;code&gt;show_qos&lt;/code&gt;<br /> * &lt;code&gt;--account=&lt;ACCOUNTNAME&gt;&lt;/code&gt; ''Requests your job runs under the &lt;ACCOUNTNAME&gt; Slurm account, different accounts have different available partitions/QOS''<br /> * &lt;code&gt;--output=&lt;OUTNAME&gt;&lt;/code&gt; ''Redirects stdout for your job to the &lt;OUTNAME&gt; file''<br /> * &lt;code&gt;--requeue&lt;/code&gt; ''Requests your job be automatically requeued if it is preempted''<br /> * &lt;code&gt;--exclusive&lt;/code&gt; ''Requests your job be the only one running on the node(s) it is assigned to. This requires that your job be allocated all of the resources on the node(s). The scheduler '''does not''' automatically give your job all of the node's/nodes' resources, however, so if you need more than the default, you still need to request these with'' &lt;code&gt;--ntasks&lt;/code&gt; ''and'' &lt;code&gt;--mem&lt;/code&gt;<br /> <br /> ===Interactive Shell Sessions===<br /> An interactive shell session on a compute node can be useful for debugging or developing code that isn't ready to be run as a batch job. To get an interactive shell on a node, use &lt;code&gt;srun&lt;/code&gt; with the &lt;code&gt;--pty&lt;/code&gt; argument to invoke a shell:<br /> &lt;pre&gt;<br /> $ srun --pty --qos=default --mem=1g --time=01:00:00 bash<br /> $ hostname<br /> tron33.umiacs.umd.edu<br /> &lt;/pre&gt;<br /> '''Please do not leave interactive shells running for long periods of time when you are not working. This blocks resources from being used by everyone else.'''<br /> <br /> ==salloc==<br /> The &lt;code&gt;salloc&lt;/code&gt; command can also be used to request resources be allocated without needing a batch script. Running salloc with a list of resources will allocate the resources you requested, create a job, and drop you into a subshell with the environment variables necessary to run commands in the newly created job allocation. When your time is up or you exit the subshell, your job allocation will be relinquished.<br /> <br /> &lt;pre&gt;<br /> $ salloc --qos=default -N 1 --mem=2g --time=01:00:00<br /> salloc: Granted job allocation 159<br /> $ srun /usr/bin/hostname<br /> tron33.umiacs.umd.edu<br /> $ exit<br /> exit<br /> salloc: Relinquishing job allocation 159<br /> &lt;/pre&gt;<br /> <br /> '''Please be careful when using salloc - any commands not invoked with srun will be run locally on the submission node.'''<br /> <br /> ==sbatch==<br /> The &lt;code&gt;sbatch&lt;/code&gt; command allows you to write a batch script to be submitted and run non-interactively on the compute nodes. To run a simple Hello World command on the compute nodes you could write a file, helloWorld.sh with the following contents:<br /> <br /> &lt;pre&gt;<br /> #!/bin/bash<br /> <br /> srun bash -c 'echo Hello World from `hostname`'<br /> &lt;/pre&gt;<br /> <br /> Then you need to submit the script with sbatch and request resources:<br /> <br /> &lt;pre&gt;<br /> $ sbatch --qos=default --mem=1g --time=1:00:00 helloWorld.sh<br /> Submitted batch job 121<br /> &lt;/pre&gt;<br /> <br /> SLURM will return a job number that you can use to check the status of your job with squeue:<br /> <br /> &lt;pre&gt;<br /> $ squeue<br /> JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)<br /> 121 tron helloWor username R 0:01 1 tron32<br /> &lt;/pre&gt;<br /> <br /> ====Advanced Batch Scripts====<br /> You can also write a batch script with all of your resources/options defined in the script itself. This is useful for jobs that need to be run tens/hundreds/thousands of times. You can then handle any necessary environment setup and run commands on the resources you requested by invoking commands with srun. The srun commands can also be more complex and be told to only use portions of your entire job allocation - each of these distinct srun commands makes up one &quot;job step&quot;. The batch script will be run on the first node allocated as part of your job allocation and each job step will be run on whatever resources you tell them to.<br /> <br /> In the following example, we have a batch job that will request 2 nodes in the cluster. We then load a specific version of [[Python]] into our environment and submit two job steps, each one using one node. Since srun blocks until the command finishes by default, we use the '&amp;' operator to background the process so that both job steps can run at once; however, this means that we then need to use the wait command to block processing until all background processes have finished.<br /> <br /> &lt;pre&gt;<br /> #!/bin/bash<br /> <br /> # Lines that begin with #SBATCH specify commands to be used by SLURM for scheduling. These MUST be above any non-#SBATCH lines in the script to take effect.<br /> <br /> #SBATCH --job-name=helloWorld # set job name<br /> #SBATCH --output=helloWorld.out.%j # indicates a file to redirect STDOUT to; %j is the jobid. If set, must be set to a file instead of a directory or else submission will fail.<br /> #SBATCH --error=helloWorld.err.%j # indicates a file to redirect STDERR to; %j is the jobid. If set, must be set to a file instead of a directory or else submission will fail.<br /> #SBATCH --time=00:05:00 # how long you would like your job to run; format=dd-hh:mm:ss<br /> #SBATCH --account=nexus # set account, this determines which partitions and QOSes are available for your job<br /> #SBATCH --partition=tron # set partition, this determines what nodes are available for your job<br /> #SBATCH --qos=default # set QOS, this determines how many resources can be requested within your job, and for how long<br /> #SBATCH --nodes=2 # number of nodes to allocate for your job<br /> #SBATCH --ntasks=4 # request 4 cpu cores be reserved for your job total<br /> #SBATCH --ntasks-per-node=2 # request 2 cpu cores be reserved per node<br /> #SBATCH --mem=1g # memory required by job; if unit is not specified MB will be assumed. for multi-node jobs, this argument allocates this much memory *per node*<br /> <br /> srun --nodes=1 --mem=512m bash -c &quot;hostname; python3 --version&quot; &amp; # use srun to invoke commands within your job; using an '&amp;'<br /> srun --nodes=1 --mem=512m bash -c &quot;hostname; python3 --version&quot; &amp; # will background the process allowing them to run concurrently<br /> wait # wait for any background processes to complete<br /> <br /> # Once the end of the batch script is reached, your job allocation will be revoked.<br /> &lt;/pre&gt;<br /> <br /> Another useful thing to know is that you can pass additional arguments into your sbatch scripts on the command line and reference them as &lt;code&gt;${1}&lt;/code&gt; for the first argument and so on.<br /> <br /> ====More Examples====<br /> * [[SLURM/ArrayJobs]]<br /> <br /> ==scancel==<br /> The &lt;code&gt;scancel&lt;/code&gt; command can be used to cancel your own job allocations or job steps that are no longer needed. It can be passed individual job IDs or an option to delete all of your jobs or jobs that meet certain criteria.<br /> *&lt;code&gt;scancel 255&lt;/code&gt; ''cancel job 255''<br /> *&lt;code&gt;scancel 255.3&lt;/code&gt; ''cancel job step 3 of job 255''<br /> *&lt;code&gt;scancel --user=username --partition=tron&lt;/code&gt; ''cancel all jobs for username in the tron partition; username must be your UMD directory ID''<br /> <br /> =Identifying Resources and Features=<br /> The &lt;code&gt;sinfo&lt;/code&gt; command can show you additional features of nodes in the cluster but you need to ask it to show some non-default options using a command like &lt;code&gt;sinfo -o &quot;%40N %8c %8m %35f %35G&quot;&lt;/code&gt;.<br /> <br /> &lt;pre&gt;<br /> $ sinfo -o &quot;%40N %10c %10m %40f %32G&quot;<br /> NODELIST CPUS MEMORY AVAIL_FEATURES GRES<br /> cbcb[00-21] 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null)<br /> cbcb25 24 255278 rhel9,x86_64,Xeon,E5-2650,Pascal,Turing gpu:rtx2080ti:1,gpu:gtx1080ti:1<br /> cbcb30 48 1157583 rhel9,x86_64,EPYC,EPYC-9475F (null)<br /> legacy00 48 125940 rhel9,x86_64,Zen,EPYC-7402 (null)<br /> legacy[01-11,13-15,17-19] 12+ 126117+ rhel9,x86_64,Xeon,E5-2620 (null)<br /> legacy[20,42,50-51] 24+ 384270+ rhel9,x86_64,Xeon,E5-2680 (null)<br /> legacy[37-40] 64 512878 rhel9,x86_64,Zen,EPYC-7502 (null)<br /> legacy[33-36,43-44] 24 255150 rhel9,x86_64,Xeon,E5-2650 (null)<br /> legacy41 8 61567 rhel9,x86_64,Zen,EPYC-7262 (null)<br /> legacy45 44 1029404 rhel9,x86_64,Xeon,E5-2699 (null)<br /> legacy[46-49] 20 384271 rhel9,x86_64,Xeon,E5-2660 (null)<br /> legacy[52-53] 20 61739 rhel9,x86_64,Xeon,E5-2640 (null)<br /> cbcb26 128 513243 rhel9,x86_64,Zen,EPYC-7763,Ampere gpu:rtxa5000:7<br /> cbcb27 64 255167 rhel9,x86_64,Zen,EPYC-7513,Ampere gpu:rtxa6000:7<br /> cbcb[28-29] 32 771166 rhel9,x86_64,Zen,EPYC-9124,Ada gpu:rtx6000ada:8<br /> tron[46-61] 48 255225+ rhel9,x86_64,Zen,EPYC-7352,Ampere gpu:rtxa5000:8<br /> tron[06-09,12-15,21] 16 126214+ rhel9,x86_64,Zen,EPYC-7302P,Ampere gpu:rtxa4000:4<br /> tron[10-11,16-20,34] 16 126217 rhel9,x86_64,Zen,EPYC-7313P,Ampere gpu:rtxa4000:4<br /> tron[22-33,35-45] 16 126214+ rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa4000:4<br /> clip04 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtx3090:4<br /> clip11 16 126217 rhel9,x86_64,Zen,EPYC-7313,Ampere gpu:rtxa4000:4<br /> clip13,cml30,vulcan[29-32,45] 32 255218+ rhel9,x86_64,Zen,EPYC-7313,Ampere gpu:rtxa6000:8<br /> clip14 32 125964 rhel9,x86_64,Xeon,Gold-6226R,Ampere gpu:rtxa5000:3<br /> clip[05-06] 24 126216 rhel9,x86_64,Zen,EPYC-7352,Ampere gpu:rtxa6000:2<br /> cml[17-28],gammagpu05 32 255225+ rhel9,x86_64,Zen,EPYC-7282,Ampere gpu:rtxa4000:8<br /> cml33 64 1029019 rhel9,x86_64,Xeon,6448Y,Hopper gpu:h100-sxm:4<br /> cml38 128 2061422 rhel9,x86_64,Xeon,6776P,Blackwell gpu:b300-sxm:8<br /> cml31 32 384094 rhel9,x86_64,Zen,EPYC-9124,Ampere,Hopper gpu:a100:1,gpu:h100-nvl:1<br /> cml32 64 512999 rhel9,x86_64,Zen,EPYC-7543,Ampere gpu:a100:4<br /> cml37 16 383918 rhel9,x86_64,Zen,EPYC-9124,Blackwell gpu:rtx6000bw-mq:4<br /> cml[00,02-03,06-07,09-11,13-16],tron[62- 32 351530+ rhel9,x86_64,Xeon,4216,Turing gpu:rtx2080ti:8<br /> cml[04-05] 32 383030 rhel9,x86_64,Xeon,4216,Turing gpu:rtx2080ti:6<br /> cml08 32 383030 rhel9,x86_64,Xeon,4216,Turing gpu:rtx2080ti:7<br /> cml12 32 383038 rhel9,x86_64,Xeon,4216,Turing,Ampere gpu:rtx2080ti:7,gpu:rtxa4000:1<br /> cml34 32 513260 rhel9,x86_64,Zen,EPYC-7313,Ada gpu:l40s:8<br /> cml[35-36],vulcan46 128 2061187+ rhel9,x86_64,Xeon,8592+,Hopper gpu:h200-sxm:8<br /> gammagpu00 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa5000:8<br /> gammagpu[01-04,06-09],vulcan[33-37] 32 255170+ rhel9,x86_64,Zen,EPYC-7313,Ampere gpu:rtxa5000:8<br /> csd00,gammagpu[18-21] 32 254883 rhel9,x86_64,Xeon,6526Y,Ada gpu:l40s:4<br /> clip12,gammagpu[10-17] 16 126203+ rhel9,x86_64,Zen,EPYC-7313,Ampere gpu:rtxa6000:4<br /> oasis[00-12,14-36,38] 160 28114 rhel9,aarch64,Altra,Altra-80 (null)<br /> quics00 128 1545009 rhel9,x86_64,Zen,EPYC-9534 (null)<br /> tron[00,03] 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa6000:6<br /> vulcan24 16 126216 rhel9,x86_64,Zen,EPYC-7282,Ampere gpu:rtxa6000:4<br /> legacygpu06 20 255249 rhel9,x86_64,Xeon,E5-2699,Maxwell gpu:gtxtitanx:4<br /> tron[01-02] 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa6000:8<br /> tron[04-05] 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa6000:7<br /> vulcan[38-44] 32 255215 rhel9,x86_64,Zen,EPYC-7313,Ampere gpu:rtxa4000:8<br /> legacygpu00 20 255249 rhel9,x86_64,Xeon,E5-2650,Pascal gpu:titanxp:4<br /> legacygpu[02,07] 20 255249+ rhel9,x86_64,Xeon,E5-2650,Maxwell gpu:gtxtitanx:4<br /> legacygpu[03-04] 16 255268 rhel9,x86_64,Xeon,E5-2630,Maxwell gpu:gtxtitanx:2<br /> legacygpu05 44 513193 rhel9,x86_64,Xeon,E5-2699,Pascal gpu:gtx1080ti:4<br /> legacygpu09 32 255276 rhel9,x86_64,Xeon,E5-2683,Pascal gpu:titanxpascal:3<br /> legacygpu10 32 255276 rhel9,x86_64,Xeon,E5-2683,Pascal gpu:titanxpascal:1,gpu:titanxp:2<br /> legacygpu11 20 126255 rhel9,x86_64,Xeon,E5-2630,Pascal gpu:gtx1080ti:3<br /> legacygpu12 20 126243 rhel9,x86_64,Xeon,E5-2630,Pascal,Turing gpu:rtx2080ti:1,gpu:gtx1080ti:2<br /> legacygpu13 8 255263 rhel9,x86_64,Xeon,E5-2623,Pascal gpu:gtx1080ti:3<br /> legacygpu[14,26-41] 32 255258+ rhel9,x86_64,Xeon,E5-2683,Pascal gpu:gtx1080ti:8<br /> legacygpu15 32 383043 rhel9,x86_64,Xeon,6130,Pascal,Turing gpu:rtx2080ti:5,gpu:gtx1080ti:3<br /> legacygpu[16-17] 20 189498 rhel9,x86_64,Xeon,4114,Turing gpu:rtx2080ti:8<br /> legacygpu18 32 255259 rhel9,x86_64,Xeon,E5-2683,Pascal gpu:p6000:7,gpu:p100:1<br /> legacygpu[19,23] 32 255259 rhel9,x86_64,Xeon,E5-2683,Pascal gpu:p6000:7<br /> legacygpu[20-22,24-25] 32 255259 rhel9,x86_64,Xeon,E5-2683,Pascal gpu:p6000:8<br /> legacygpu42 24 770126 rhel9,x86_64,Xeon,6146,Pascal gpu:titanxp:10<br /> tron[64,67] 32 383028+ rhel9,x86_64,Xeon,4216,Turing,Ampere gpu:rtx2080ti:7,gpu:rtx3070:1<br /> brigid[16-17] 48 512897 rhel9,x86_64,Zen,EPYC-7443 (null)<br /> vulcan23 32 383030 rhel9,x86_64,Xeon,4612,Turing gpu:rtx2080ti:6<br /> vulcan[27-28] 56 770093 rhel9,x86_64,Xeon,8280,Turing gpu:rtx2080ti:10<br /> &lt;/pre&gt;<br /> <br /> Note that all of the nodes shown by this may not necessarily be in a partition you are able to submit to.<br /> <br /> You can identify further specific information about a node using [[SLURM/ClusterStatus#scontrol | scontrol]] with various flags.<br /> <br /> There are also two command aliases developed by UMIACS staff to show various node information in aggregate. They are &lt;code&gt;show_nodes&lt;/code&gt; and &lt;code&gt;show_available_nodes&lt;/code&gt;.<br /> <br /> ==show_nodes==<br /> The &lt;code&gt;show_nodes&lt;/code&gt; command alias shows each node's name, number of CPUs, memory, {OS, CPU architecture, CPU type, GPU architecture (if the node has GPUs)} (as AVAIL_FEATURES), GRES (GPUs), and State. It essentially wraps the &lt;tt&gt;sinfo&lt;/tt&gt; command with some pre-determined output format options and shows each node on its own line, in alphabetical order.<br /> <br /> To only view nodes in a specific partition, append &lt;code&gt;-p &lt;partition name&gt;&lt;/code&gt; to the command alias.<br /> <br /> ===Examples===<br /> &lt;pre&gt;<br /> $ show_nodes<br /> NODELIST CPUS MEMORY AVAIL_FEATURES GRES STATE<br /> brigid16 48 512897 rhel9,x86_64,Zen,EPYC-7443 (null) idle<br /> brigid17 48 512897 rhel9,x86_64,Zen,EPYC-7443 (null) idle<br /> ... ... ... ... ... ...<br /> vulcan45 32 513250 rhel9,x86_64,Zen,EPYC-7313,Ampere gpu:rtxa6000:8 idle<br /> &lt;/pre&gt;<br /> <br /> (specific partition)<br /> &lt;pre&gt;<br /> $ show_nodes -p tron<br /> NODELIST CPUS MEMORY AVAIL_FEATURES GRES STATE<br /> tron00 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa6000:8 idle<br /> tron01 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa6000:8 idle<br /> ... ... ... ... ... ...<br /> tron69 32 383030 rhel9,x86_64,Xeon,4216,Turing gpu:rtx2080ti:8 idle<br /> &lt;/pre&gt;<br /> <br /> ==show_available_nodes==<br /> The &lt;code&gt;show_available_nodes&lt;/code&gt; command alias takes zero or more arguments that correspond to Slurm constructs, resources, or features that you are looking to request a job with and tells you what nodes could '''theoretically'''[0,1] run a job with these arguments immediately. It assumes your job is a single-node job.<br /> <br /> These arguments are:<br /> * &lt;code&gt;--partition&lt;/code&gt;: Only include nodes in the specified partition(s).<br /> * &lt;code&gt;--account&lt;/code&gt;: Only include nodes from partitions that can use the specified account(s).<br /> * &lt;code&gt;--qos&lt;/code&gt;: Only include nodes from partitions that can use the specified QoS(es).<br /> * &lt;code&gt;--cpus&lt;/code&gt;: Only include nodes with at least this many CPUs free.<br /> * &lt;code&gt;--mem&lt;/code&gt;: Only include nodes with at least this much memory free. The default unit is MB if unspecified, but any of {K,M,G,T} can be suffixed to the number provided (will then be interpreted as KB, MB, GB, or TB, respectively).<br /> * GRES-related arguments:<br /> ** &lt;code&gt;--gres&lt;/code&gt;, &lt;code&gt;--and-gres&lt;/code&gt;: Only include nodes whose list of GRES contains ''all'' of the specified GRES type/quantity pairings.<br /> ** &lt;code&gt;--or-gres&lt;/code&gt;: Only include nodes whose list of GRES contains ''any'' of the specified GRES type/quantity pairings. Functionally identical to &lt;tt&gt;--and-gres&lt;/tt&gt; if only one GRES type/quantity pairing is specified.<br /> * GPU-related arguments:<br /> ** &lt;code&gt;--gpus&lt;/code&gt;, &lt;code&gt;--and-gpus&lt;/code&gt;: Only include nodes whose list of GPUs (a subset of GRES) contains ''all'' of the specified GPU type/quantity pairings.<br /> ** &lt;code&gt;--or-gpus&lt;/code&gt;: Only include nodes whose list of GPUs (a subset of GRES) contains ''any'' of the specified GPU type/quantity pairings. Functionally identical to &lt;tt&gt;--and-gpus&lt;/tt&gt; if only one GPU type/quantity pairing is specified.<br /> * Feature-related arguments:<br /> ** &lt;code&gt;--feature&lt;/code&gt;, &lt;code&gt;--and-feature&lt;/code&gt;: Only include nodes whose list of features contains ''all'' of the specified feature(s).<br /> ** &lt;code&gt;--or-feature&lt;/code&gt;: Only include nodes whose list of features contains ''any'' of the specified feature(s). Functionally identical to &lt;tt&gt;--and-feature&lt;/tt&gt; if only one feature is specified.<br /> <br /> These arguments are also viewable by running &lt;code&gt;show_available_nodes -h&lt;/code&gt;.<br /> <br /> If your passed argument set does not contain any resource-based arguments (CPUs/RAM/GRES or GPUs), a node is defined as available if it has at least 1 CPU and 1MB of RAM available.<br /> <br /> If there are no nodes available that meet your passed argument set, you will receive the message &lt;tt&gt;There are no nodes that have currently free resources that meet this argument set.&lt;/tt&gt;<br /> <br /> ===Footnotes===<br /> [0] - As of now, this command alias does not factor in resources occupied by jobs that could be preempted (based on the partition(s) passed to it, if present). This is something that we are working on implementing.<br /> <br /> [1] - This command alias also does not factor in jobs with higher priority values requesting more resources, in the same partition(s), blocking execution of a job submitted with the resources / other arguments checked by the command alias. This is due to the infeasibility of calculating a job's priority value before it is actually submitted.<br /> <br /> ===Examples===<br /> Show all available nodes:<br /> &lt;pre&gt;<br /> $ show_available_nodes<br /> brigid16<br /> cpus=16,mem=200573M<br /> brigid17<br /> cpus=16,mem=414593M<br /> ...<br /> &lt;/pre&gt;<br /> <br /> Show nodes available in the &lt;tt&gt;tron&lt;/tt&gt; partition:<br /> &lt;pre&gt;<br /> $ show_available_nodes --partition=tron<br /> tron00<br /> cpus=14,mem=50433M,gres=gpu:rtxa6000:1<br /> tron01<br /> cpus=10,mem=17665M,gres=gpu:rtxa6000:2<br /> ...<br /> &lt;/pre&gt;<br /> <br /> Show nodes with one or more RTX A5000 or RTX A6000 GPUs available to the &lt;tt&gt;vulcan&lt;/tt&gt; account:<br /> &lt;pre&gt;<br /> $ show_available_nodes --account=vulcan --or-gpus=rtxa5000:1,rtxa6000:1<br /> vulcan32<br /> cpus=16,mem=193778M,gres=gpu:rtxa6000:4<br /> vulcan33<br /> cpus=15,mem=181499M,gres=gpu:rtxa5000:3<br /> ...<br /> &lt;/pre&gt;<br /> <br /> Show nodes with 4 or more CPUs, 48G or more memory, and one or more RTX A6000 GPUs available in the &lt;tt&gt;scavenger&lt;/tt&gt; partition:<br /> &lt;pre&gt;<br /> $ show_available_nodes --partition=scavenger --cpus=4 --mem=48g --or-gpus=rtxa6000:1<br /> cbcb27<br /> cpus=59,mem=218303M,gres=gpu:rtxa6000:6<br /> clip06<br /> cpus=20,mem=93448M,gres=gpu:rtxa6000:1<br /> ...<br /> &lt;/pre&gt;<br /> <br /> Show nodes with [https://en.wikipedia.org/wiki/Turing_(microarchitecture) Turing] or [https://en.wikipedia.org/wiki/Ampere_(microarchitecture) Ampere] architecture GPUs available in the &lt;tt&gt;scavenger&lt;/tt&gt; partition:<br /> &lt;pre&gt;<br /> $ show_available_nodes --partition=scavenger --or-feature=Ampere,Turing<br /> cbcb25<br /> cpus=24,mem=255278M,gres=gpu:rtx2080ti:1,gpu:gtx1080ti:1<br /> cbcb26<br /> cpus=127,mem=447707M,gres=gpu:rtxa5000:7<br /> ...<br /> &lt;/pre&gt;<br /> <br /> Show nodes with [https://en.wikipedia.org/wiki/Zen_(microarchitecture) Zen] architecture CPUs and [https://en.wikipedia.org/wiki/Ampere_(microarchitecture) Ampere] architecture GPUs available in the &lt;tt&gt;scavenger&lt;/tt&gt; partition:<br /> &lt;pre&gt;<br /> $ show_available_nodes --partition=scavenger --and-feature=Zen,Ampere<br /> cbcb26<br /> cpus=127,mem=447707M,gres=gpu:rtxa5000:7<br /> cbcb27<br /> cpus=59,mem=218303M,gres=gpu:rtxa6000:6<br /> ...<br /> &lt;/pre&gt;<br /> <br /> (bogus example) Attempt to show nodes available in the &lt;tt&gt;bogus&lt;/tt&gt; partition:<br /> &lt;pre&gt;<br /> $ show_available_nodes --partition=bogus<br /> There are no nodes that have currently free resources that meet this argument set.<br /> &lt;/pre&gt;<br /> <br /> =Requesting GPUs=<br /> If you need to do processing on a GPU, you will need to request that your job have access to GPUs just as you need to request processors or CPU cores. In SLURM, GPUs are considered &quot;generic resources&quot; also known as GRES. To request some number of GPUs be reserved/available for your job, you can use the flag &lt;code&gt;--gres=gpu:#&lt;/code&gt; (with the actual number of GPUs you want). If there are multiple types of GPUs available in the cluster and you need a specific type, you can provide the type option to the gres flag e.g. &lt;code&gt;--gres=gpu:rtxa5000:#&lt;/code&gt;. If you do not request a specific type of GPU, you are likely to be scheduled on an older, lower spec'd GPU.<br /> <br /> Note that some QoSes may have limits on the number of GPUs you can request per job, so you may need to specify a different QoS to request more GPUs.<br /> <br /> &lt;pre&gt;<br /> $ srun --pty --qos=medium --gres=gpu:2 nvidia-smi<br /> ...<br /> Wed Mar 6 16:59:39 2024<br /> +---------------------------------------------------------------------------------------+<br /> | NVIDIA-SMI 535.129.03 Driver Version: 535.129.03 CUDA Version: 12.2 |<br /> |-----------------------------------------+----------------------+----------------------+<br /> | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |<br /> | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |<br /> | | | MIG M. |<br /> |=========================================+======================+======================|<br /> | 0 NVIDIA GeForce RTX 2080 Ti Off | 00000000:3D:00.0 Off | N/A |<br /> | 32% 23C P8 1W / 250W | 0MiB / 11264MiB | 0% Default |<br /> | | | N/A |<br /> +-----------------------------------------+----------------------+----------------------+<br /> | 1 NVIDIA GeForce RTX 2080 Ti Off | 00000000:40:00.0 Off | N/A |<br /> | 32% 25C P8 1W / 250W | 0MiB / 11264MiB | 0% Default |<br /> | | | N/A |<br /> +-----------------------------------------+----------------------+----------------------+<br /> <br /> +---------------------------------------------------------------------------------------+<br /> | Processes: |<br /> | GPU GI CI PID Type Process name GPU Memory |<br /> | ID ID Usage |<br /> |=======================================================================================|<br /> | No running processes found |<br /> +---------------------------------------------------------------------------------------+<br /> &lt;/pre&gt;<br /> <br /> Please note that your job will only be able to see/access the GPUs you requested. If you only need 1 GPU, please only request 1 GPU. The others on the node (if any) will be left available for other users.<br /> <br /> &lt;pre&gt;<br /> $ srun --pty --gres=gpu:rtxa5000:1 nvidia-smi<br /> Thu Aug 25 15:22:15 2022<br /> +-----------------------------------------------------------------------------+<br /> | NVIDIA-SMI 470.129.06 Driver Version: 470.129.06 CUDA Version: 11.4 |<br /> |-------------------------------+----------------------+----------------------+<br /> | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |<br /> | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |<br /> | | | MIG M. |<br /> |===============================+======================+======================|<br /> | 0 NVIDIA RTX A5000 Off | 00000000:01:00.0 Off | Off |<br /> | 30% 23C P8 20W / 230W | 0MiB / 24256MiB | 0% Default |<br /> | | | N/A |<br /> +-------------------------------+----------------------+----------------------+<br /> <br /> +-----------------------------------------------------------------------------+<br /> | Processes: GPU Memory |<br /> | GPU PID Type Process name Usage |<br /> |=============================================================================|<br /> | No running processes found |<br /> +-----------------------------------------------------------------------------+<br /> &lt;/pre&gt;<br /> <br /> As with all other flags, the &lt;code&gt;--gres&lt;/code&gt; flag may also be passed to [[#sbatch | sbatch]] and [[#salloc | salloc]] rather than directly to [[#srun | srun]].<br /> <br /> =MPI example=<br /> To run [https://en.wikipedia.org/wiki/Message_Passing_Interface MPI] jobs, you will need to include the &lt;code&gt;--mpi=pmix&lt;/code&gt; flag in your submission arguments.<br /> <br /> &lt;pre&gt;<br /> #!/usr/bin/bash <br /> #SBATCH --job-name=mpi_test # Job name <br /> #SBATCH --nodes=4 # Number of nodes <br /> #SBATCH --ntasks=8 # Number of MPI ranks <br /> #SBATCH --ntasks-per-node=2 # Number of MPI ranks per node <br /> #SBATCH --ntasks-per-socket=1 # Number of tasks per processor socket on the node <br /> #SBATCH --time=00:30:00 # Time limit hrs:min:sec <br /> <br /> <br /> srun --mpi=pmix /nfshomes/username/testing/mpi/a.out <br /> &lt;/pre&gt;</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=SLURM/JobSubmission&diff=13367 2026-08-28T15:23:14Z

<p>Mbaney: /* Identifying Resources and Features */</p> <hr /> <div>=Job Submission=<br /> SLURM offers a variety of ways to run jobs. It is important to understand the different options available and how to request the resources required for a job in order for it to run successfully. All job submission should be done from submit nodes; any computational code should be run in a job allocation on compute nodes. The following commands outline how to allocate resources on the compute nodes and submit processes to be run on the allocated nodes.<br /> <br /> The cluster that everyone with a [[Accounts#UMIACS_Account | UMIACS account]] has access to is [[Nexus]]. Please visit the Nexus page for instructions on how to connect to your assigned submit nodes.<br /> <br /> '''Computationally intensive processes run on submission nodes will be terminated. Please submit jobs to be scheduled on compute nodes for this purpose.'''<br /> <br /> For details on how SLURM decides how to schedule jobs when multiple jobs are waiting in a scheduler's queue, please see [[SLURM/Priority]].<br /> <br /> ==srun==<br /> The &lt;code&gt;srun&lt;/code&gt; command is used to run a process on the compute nodes in the cluster. If you pass it a normal shell command (or command that executes a script), it will submit a job to run that shell command/script on a compute node and then return. &lt;code&gt;srun&lt;/code&gt; accepts many command line options to specify the resources required by the command passed to it. Some common command line arguments are listed below and full documentation of all available options is available in the man page for &lt;code&gt;srun&lt;/code&gt;, which can be accessed by running &lt;code&gt;man srun&lt;/code&gt;.<br /> <br /> &lt;pre&gt;<br /> $ srun --qos=default --mem=100mb --time=1:00:00 bash -c 'echo &quot;Hello World from&quot; `hostname`'<br /> Hello World from tron33.umiacs.umd.edu<br /> &lt;/pre&gt;<br /> <br /> It is important to understand that &lt;code&gt;srun&lt;/code&gt; is an interactive command. By default input to &lt;code&gt;srun&lt;/code&gt; is broadcast to all compute nodes running your process and output from the compute nodes is redirected to &lt;code&gt;srun&lt;/code&gt;. This behavior can be changed; however, '''srun will always wait for the command passed to finish before exiting, so if you start a long running process and end your terminal session, your process will stop running on the compute nodes and your job will end'''. To run a non-interactive submission that will remain running after you logout, you will need to wrap your &lt;code&gt;srun&lt;/code&gt; commands in a batch script and submit it with [[#sbatch | sbatch]].<br /> <br /> ===Common srun Arguments===<br /> * &lt;code&gt;--job-name=&lt;JOBNAME&gt;&lt;/code&gt; ''Requests your job be named &lt;JOBNAME&gt;''<br /> * &lt;code&gt;--mem=1g&lt;/code&gt; ''Requests 1GB of memory for your job, if no unit is given MB is assumed''<br /> * &lt;code&gt;--ntasks=2&lt;/code&gt; ''Requests 2 &quot;tasks&quot; which map to cores on a CPU for your job; if passed to srun, runs the given command concurrently on each core''<br /> * &lt;code&gt;--cpus-per-task=2&lt;/code&gt; ''Requests 2 CPU cores be allocated per task for your job''<br /> * &lt;code&gt;--nodes=2&lt;/code&gt; ''Requests 2 nodes be allocated to your job; if passed to srun, runs the given command concurrently on each node''<br /> * &lt;code&gt;--nodelist=&lt;NODENAME&gt;&lt;/code&gt; ''Requests to run your job on the &lt;NODENAME&gt; node''<br /> * &lt;code&gt;--time=dd-hh:mm:ss&lt;/code&gt; ''Requests your job run for dd days, hh hours, mm minutes, and ss seconds''<br /> * &lt;code&gt;--error=&lt;ERRNAME&gt;&lt;/code&gt; ''Redirects stderr for your job to the &lt;ERRNAME&gt; file''<br /> * &lt;code&gt;--partition=&lt;PARTITIONNAME&gt;&lt;/code&gt; ''Requests your job run in the &lt;PARTITIONNAME&gt; partition''<br /> * &lt;code&gt;--qos=&lt;QOSNAME&gt;default&lt;/code&gt; ''Requests your job run with the &lt;QOSNAME&gt; QOS, to see the available QOS options on a cluster, run'' &lt;code&gt;show_qos&lt;/code&gt;<br /> * &lt;code&gt;--account=&lt;ACCOUNTNAME&gt;&lt;/code&gt; ''Requests your job runs under the &lt;ACCOUNTNAME&gt; Slurm account, different accounts have different available partitions/QOS''<br /> * &lt;code&gt;--output=&lt;OUTNAME&gt;&lt;/code&gt; ''Redirects stdout for your job to the &lt;OUTNAME&gt; file''<br /> * &lt;code&gt;--requeue&lt;/code&gt; ''Requests your job be automatically requeued if it is preempted''<br /> * &lt;code&gt;--exclusive&lt;/code&gt; ''Requests your job be the only one running on the node(s) it is assigned to. This requires that your job be allocated all of the resources on the node(s). The scheduler '''does not''' automatically give your job all of the node's/nodes' resources, however, so if you need more than the default, you still need to request these with'' &lt;code&gt;--ntasks&lt;/code&gt; ''and'' &lt;code&gt;--mem&lt;/code&gt;<br /> <br /> ===Interactive Shell Sessions===<br /> An interactive shell session on a compute node can be useful for debugging or developing code that isn't ready to be run as a batch job. To get an interactive shell on a node, use &lt;code&gt;srun&lt;/code&gt; with the &lt;code&gt;--pty&lt;/code&gt; argument to invoke a shell:<br /> &lt;pre&gt;<br /> $ srun --pty --qos=default --mem=1g --time=01:00:00 bash<br /> $ hostname<br /> tron33.umiacs.umd.edu<br /> &lt;/pre&gt;<br /> '''Please do not leave interactive shells running for long periods of time when you are not working. This blocks resources from being used by everyone else.'''<br /> <br /> ==salloc==<br /> The &lt;code&gt;salloc&lt;/code&gt; command can also be used to request resources be allocated without needing a batch script. Running salloc with a list of resources will allocate the resources you requested, create a job, and drop you into a subshell with the environment variables necessary to run commands in the newly created job allocation. When your time is up or you exit the subshell, your job allocation will be relinquished.<br /> <br /> &lt;pre&gt;<br /> $ salloc --qos=default -N 1 --mem=2g --time=01:00:00<br /> salloc: Granted job allocation 159<br /> $ srun /usr/bin/hostname<br /> tron33.umiacs.umd.edu<br /> $ exit<br /> exit<br /> salloc: Relinquishing job allocation 159<br /> &lt;/pre&gt;<br /> <br /> '''Please be careful when using salloc - any commands not invoked with srun will be run locally on the submission node.'''<br /> <br /> ==sbatch==<br /> The &lt;code&gt;sbatch&lt;/code&gt; command allows you to write a batch script to be submitted and run non-interactively on the compute nodes. To run a simple Hello World command on the compute nodes you could write a file, helloWorld.sh with the following contents:<br /> <br /> &lt;pre&gt;<br /> #!/bin/bash<br /> <br /> srun bash -c 'echo Hello World from `hostname`'<br /> &lt;/pre&gt;<br /> <br /> Then you need to submit the script with sbatch and request resources:<br /> <br /> &lt;pre&gt;<br /> $ sbatch --qos=default --mem=1g --time=1:00:00 helloWorld.sh<br /> Submitted batch job 121<br /> &lt;/pre&gt;<br /> <br /> SLURM will return a job number that you can use to check the status of your job with squeue:<br /> <br /> &lt;pre&gt;<br /> $ squeue<br /> JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)<br /> 121 tron helloWor username R 0:01 1 tron32<br /> &lt;/pre&gt;<br /> <br /> ====Advanced Batch Scripts====<br /> You can also write a batch script with all of your resources/options defined in the script itself. This is useful for jobs that need to be run tens/hundreds/thousands of times. You can then handle any necessary environment setup and run commands on the resources you requested by invoking commands with srun. The srun commands can also be more complex and be told to only use portions of your entire job allocation - each of these distinct srun commands makes up one &quot;job step&quot;. The batch script will be run on the first node allocated as part of your job allocation and each job step will be run on whatever resources you tell them to.<br /> <br /> In the following example, we have a batch job that will request 2 nodes in the cluster. We then load a specific version of [[Python]] into our environment and submit two job steps, each one using one node. Since srun blocks until the command finishes by default, we use the '&amp;' operator to background the process so that both job steps can run at once; however, this means that we then need to use the wait command to block processing until all background processes have finished.<br /> <br /> &lt;pre&gt;<br /> #!/bin/bash<br /> <br /> # Lines that begin with #SBATCH specify commands to be used by SLURM for scheduling. These MUST be above any non-#SBATCH lines in the script to take effect.<br /> <br /> #SBATCH --job-name=helloWorld # set job name<br /> #SBATCH --output=helloWorld.out.%j # indicates a file to redirect STDOUT to; %j is the jobid. If set, must be set to a file instead of a directory or else submission will fail.<br /> #SBATCH --error=helloWorld.err.%j # indicates a file to redirect STDERR to; %j is the jobid. If set, must be set to a file instead of a directory or else submission will fail.<br /> #SBATCH --time=00:05:00 # how long you would like your job to run; format=dd-hh:mm:ss<br /> #SBATCH --account=nexus # set account, this determines which partitions and QOSes are available for your job<br /> #SBATCH --partition=tron # set partition, this determines what nodes are available for your job<br /> #SBATCH --qos=default # set QOS, this determines how many resources can be requested within your job, and for how long<br /> #SBATCH --nodes=2 # number of nodes to allocate for your job<br /> #SBATCH --ntasks=4 # request 4 cpu cores be reserved for your job total<br /> #SBATCH --ntasks-per-node=2 # request 2 cpu cores be reserved per node<br /> #SBATCH --mem=1g # memory required by job; if unit is not specified MB will be assumed. for multi-node jobs, this argument allocates this much memory *per node*<br /> <br /> srun --nodes=1 --mem=512m bash -c &quot;hostname; python3 --version&quot; &amp; # use srun to invoke commands within your job; using an '&amp;'<br /> srun --nodes=1 --mem=512m bash -c &quot;hostname; python3 --version&quot; &amp; # will background the process allowing them to run concurrently<br /> wait # wait for any background processes to complete<br /> <br /> # Once the end of the batch script is reached, your job allocation will be revoked.<br /> &lt;/pre&gt;<br /> <br /> Another useful thing to know is that you can pass additional arguments into your sbatch scripts on the command line and reference them as &lt;code&gt;${1}&lt;/code&gt; for the first argument and so on.<br /> <br /> ====More Examples====<br /> * [[SLURM/ArrayJobs]]<br /> <br /> ==scancel==<br /> The &lt;code&gt;scancel&lt;/code&gt; command can be used to cancel your own job allocations or job steps that are no longer needed. It can be passed individual job IDs or an option to delete all of your jobs or jobs that meet certain criteria.<br /> *&lt;code&gt;scancel 255&lt;/code&gt; ''cancel job 255''<br /> *&lt;code&gt;scancel 255.3&lt;/code&gt; ''cancel job step 3 of job 255''<br /> *&lt;code&gt;scancel --user=username --partition=tron&lt;/code&gt; ''cancel all jobs for username in the tron partition; username must be your UMD directory ID''<br /> <br /> =Identifying Resources and Features=<br /> The &lt;code&gt;sinfo&lt;/code&gt; command can show you additional features of nodes in the cluster but you need to ask it to show some non-default options using a command like &lt;code&gt;sinfo -o &quot;%40N %8c %8m %35f %35G&quot;&lt;/code&gt;.<br /> <br /> &lt;pre&gt;<br /> $ sinfo -o &quot;%40N %10c %10m %40f %32G&quot;<br /> NODELIST CPUS MEMORY AVAIL_FEATURES GRES<br /> cbcb[00-21] 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null)<br /> cbcb25 24 255278 rhel9,x86_64,Xeon,E5-2650,Pascal,Turing gpu:rtx2080ti:1,gpu:gtx1080ti:1<br /> cbcb30 48 1157583 rhel9,x86_64,EPYC,EPYC-9475F (null)<br /> legacy00 48 125940 rhel9,x86_64,Zen,EPYC-7402 (null)<br /> legacy[01-11,13-15,17-19] 12+ 126117+ rhel9,x86_64,Xeon,E5-2620 (null)<br /> legacy[20,42,50-51] 24+ 384270+ rhel9,x86_64,Xeon,E5-2680 (null)<br /> legacy[37-40] 64 512878 rhel9,x86_64,Zen,EPYC-7502 (null)<br /> legacy[33-36,43-44] 24 255150 rhel9,x86_64,Xeon,E5-2650 (null)<br /> legacy41 8 61567 rhel9,x86_64,Zen,EPYC-7262 (null)<br /> legacy45 44 1029404 rhel9,x86_64,Xeon,E5-2699 (null)<br /> legacy[46-49] 20 384271 rhel9,x86_64,Xeon,E5-2660 (null)<br /> legacy[52-53] 20 61739 rhel9,x86_64,Xeon,E5-2640 (null)<br /> cbcb26 128 513243 rhel9,x86_64,Zen,EPYC-7763,Ampere gpu:rtxa5000:7<br /> cbcb27 64 255167 rhel9,x86_64,Zen,EPYC-7513,Ampere gpu:rtxa6000:7<br /> cbcb[28-29] 32 771166 rhel9,x86_64,Zen,EPYC-9124,Ada gpu:rtx6000ada:8<br /> tron[46-61] 48 255225+ rhel9,x86_64,Zen,EPYC-7352,Ampere gpu:rtxa5000:8<br /> tron[06-09,12-15,21] 16 126214+ rhel9,x86_64,Zen,EPYC-7302P,Ampere gpu:rtxa4000:4<br /> tron[10-11,16-20,34] 16 126217 rhel9,x86_64,Zen,EPYC-7313P,Ampere gpu:rtxa4000:4<br /> tron[22-33,35-45] 16 126214+ rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa4000:4<br /> clip04 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtx3090:4<br /> clip11 16 126217 rhel9,x86_64,Zen,EPYC-7313,Ampere gpu:rtxa4000:4<br /> clip13,cml30,vulcan[29-32,45] 32 255218+ rhel9,x86_64,Zen,EPYC-7313,Ampere gpu:rtxa6000:8<br /> clip14 32 125964 rhel9,x86_64,Xeon,Gold-6226R,Ampere gpu:rtxa5000:3<br /> clip[05-06] 24 126216 rhel9,x86_64,Zen,EPYC-7352,Ampere gpu:rtxa6000:2<br /> cml[17-28],gammagpu05 32 255225+ rhel9,x86_64,Zen,EPYC-7282,Ampere gpu:rtxa4000:8<br /> cml33 64 1029019 rhel9,x86_64,Xeon,6448Y,Hopper gpu:h100-sxm:4<br /> cml38 128 2061422 rhel9,x86_64,Xeon,6776P,Blackwell gpu:b300-sxm:8<br /> cml31 32 384094 rhel9,x86_64,Zen,EPYC-9124,Ampere,Hopper gpu:a100:1,gpu:h100-nvl:1<br /> cml32 64 512999 rhel9,x86_64,Zen,EPYC-7543,Ampere gpu:a100:4<br /> cml37 16 383918 rhel9,x86_64,Zen,EPYC-9124,Blackwell gpu:rtx6000bw-mq:4<br /> cml[00,02-03,06-07,09-11,13-16],tron[62- 32 351530+ rhel9,x86_64,Xeon,4216,Turing gpu:rtx2080ti:8<br /> cml[04-05] 32 383030 rhel9,x86_64,Xeon,4216,Turing gpu:rtx2080ti:6<br /> cml08 32 383030 rhel9,x86_64,Xeon,4216,Turing gpu:rtx2080ti:7<br /> cml12 32 383038 rhel9,x86_64,Xeon,4216,Turing,Ampere gpu:rtx2080ti:7,gpu:rtxa4000:1<br /> cml34 32 513260 rhel9,x86_64,Zen,EPYC-7313,Ada gpu:l40s:8<br /> cml[35-36],vulcan46 128 2061187+ rhel9,x86_64,Xeon,8592+,Hopper gpu:h200-sxm:8<br /> gammagpu00 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa5000:8<br /> gammagpu[01-04,06-09],vulcan[33-37] 32 255170+ rhel9,x86_64,Zen,EPYC-7313,Ampere gpu:rtxa5000:8<br /> csd00,gammagpu[18-21] 32 254883 rhel9,x86_64,Xeon,6526Y,Ada gpu:l40s:4<br /> clip12,gammagpu[10-17] 16 126203+ rhel9,x86_64,Zen,EPYC-7313,Ampere gpu:rtxa6000:4<br /> oasis[00-12,14-36,38] 160 28114 rhel9,aarch64,Altra,Altra-80 (null)<br /> quics00 128 1545009 rhel9,x86_64,Zen,EPYC-9534 (null)<br /> tron[00,03] 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa6000:6<br /> vulcan24 16 126216 rhel9,x86_64,Zen,EPYC-7282,Ampere gpu:rtxa6000:4<br /> legacygpu06 20 255249 rhel9,x86_64,Xeon,E5-2699,Maxwell gpu:gtxtitanx:4<br /> tron[01-02] 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa6000:8<br /> tron[04-05] 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa6000:7<br /> vulcan[38-44] 32 255215 rhel9,x86_64,Zen,EPYC-7313,Ampere gpu:rtxa4000:8<br /> legacygpu00 20 255249 rhel9,x86_64,Xeon,E5-2650,Pascal gpu:titanxp:4<br /> legacygpu[02,07] 20 255249+ rhel9,x86_64,Xeon,E5-2650,Maxwell gpu:gtxtitanx:4<br /> legacygpu[03-04] 16 255268 rhel9,x86_64,Xeon,E5-2630,Maxwell gpu:gtxtitanx:2<br /> legacygpu05 44 513193 rhel9,x86_64,Xeon,E5-2699,Pascal gpu:gtx1080ti:4<br /> legacygpu09 32 255276 rhel9,x86_64,Xeon,E5-2683,Pascal gpu:titanxpascal:3<br /> legacygpu10 32 255276 rhel9,x86_64,Xeon,E5-2683,Pascal gpu:titanxpascal:1,gpu:titanxp:2<br /> legacygpu11 20 126255 rhel9,x86_64,Xeon,E5-2630,Pascal gpu:gtx1080ti:3<br /> legacygpu12 20 126243 rhel9,x86_64,Xeon,E5-2630,Pascal,Turing gpu:rtx2080ti:1,gpu:gtx1080ti:2<br /> legacygpu13 8 255263 rhel9,x86_64,Xeon,E5-2623,Pascal gpu:gtx1080ti:3<br /> legacygpu[14,26-41] 32 255258+ rhel9,x86_64,Xeon,E5-2683,Pascal gpu:gtx1080ti:8<br /> legacygpu15 32 383043 rhel9,x86_64,Xeon,6130,Pascal,Turing gpu:rtx2080ti:5,gpu:gtx1080ti:3<br /> legacygpu[16-17] 20 189498 rhel9,x86_64,Xeon,4114,Turing gpu:rtx2080ti:8<br /> legacygpu18 32 255259 rhel9,x86_64,Xeon,E5-2683,Pascal gpu:p6000:7,gpu:p100:1<br /> legacygpu[19,23] 32 255259 rhel9,x86_64,Xeon,E5-2683,Pascal gpu:p6000:7<br /> legacygpu[20-22,24-25] 32 255259 rhel9,x86_64,Xeon,E5-2683,Pascal gpu:p6000:8<br /> legacygpu42 24 770126 rhel9,x86_64,Xeon,6146,Pascal gpu:titanxp:10<br /> tron[64,67] 32 383028+ rhel9,x86_64,Xeon,4216,Turing,Ampere gpu:rtx2080ti:7,gpu:rtx3070:1<br /> brigid[16-17] 48 512897 rhel9,x86_64,Zen,EPYC-7443 (null)<br /> vulcan23 32 383030 rhel9,x86_64,Xeon,4612,Turing gpu:rtx2080ti:6<br /> vulcan[27-28] 56 770093 rhel9,x86_64,Xeon,8280,Turing gpu:rtx2080ti:10<br /> &lt;/pre&gt;<br /> <br /> Note that all of the nodes shown by this may not necessarily be in a partition you are able to submit to.<br /> <br /> You can identify further specific information about a node using [[SLURM/ClusterStatus#scontrol | scontrol]] with various flags.<br /> <br /> There are also two command aliases developed by UMIACS staff to show various node information in aggregate. They are &lt;code&gt;show_nodes&lt;/code&gt; and &lt;code&gt;show_available_nodes&lt;/code&gt;.<br /> <br /> ==show_nodes==<br /> The &lt;code&gt;show_nodes&lt;/code&gt; command alias shows each node's name, number of CPUs, memory, {OS, CPU architecture, CPU type, GPU architecture (if the node has GPUs)} (as AVAIL_FEATURES), GRES (GPUs), and State. It essentially wraps the &lt;tt&gt;sinfo&lt;/tt&gt; command with some pre-determined output format options and shows each node on its own line, in alphabetical order.<br /> <br /> To only view nodes in a specific partition, append &lt;code&gt;-p &lt;partition name&gt;&lt;/code&gt; to the command alias.<br /> <br /> ===Examples===<br /> &lt;pre&gt;<br /> $ show_nodes<br /> NODELIST CPUS MEMORY AVAIL_FEATURES GRES STATE<br /> brigid16 48 512897 rhel9,x86_64,Zen,EPYC-7443 (null) idle<br /> brigid17 48 512897 rhel9,x86_64,Zen,EPYC-7443 (null) idle<br /> ... ... ... ... ... ...<br /> vulcan45 32 513250 rhel9,x86_64,Zen,EPYC-7313,Ampere gpu:rtxa6000:8 idle<br /> &lt;/pre&gt;<br /> <br /> (specific partition)<br /> &lt;pre&gt;<br /> $ show_nodes -p tron<br /> NODELIST CPUS MEMORY AVAIL_FEATURES GRES STATE<br /> tron00 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa6000:8 idle<br /> tron01 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa6000:8 idle<br /> ... ... ... ... ... ...<br /> tron69 32 383030 rhel9,x86_64,Xeon,4216,Turing gpu:rtx2080ti:8 idle<br /> &lt;/pre&gt;<br /> <br /> ==show_available_nodes==<br /> The &lt;code&gt;show_available_nodes&lt;/code&gt; command alias takes zero or more arguments that correspond to Slurm constructs, resources, or features that you are looking to request a job with and tells you what nodes could '''theoretically'''[0,1] run a job with these arguments immediately. It assumes your job is a single-node job.<br /> <br /> These arguments are:<br /> * &lt;code&gt;--partition&lt;/code&gt;: Only include nodes in the specified partition(s).<br /> * &lt;code&gt;--account&lt;/code&gt;: Only include nodes from partitions that can use the specified account(s).<br /> * &lt;code&gt;--qos&lt;/code&gt;: Only include nodes from partitions that can use the specified QoS(es).<br /> * &lt;code&gt;--cpus&lt;/code&gt;: Only include nodes with at least this many CPUs free.<br /> * &lt;code&gt;--mem&lt;/code&gt;: Only include nodes with at least this much memory free. The default unit is MB if unspecified, but any of {K,M,G,T} can be suffixed to the number provided (will then be interpreted as KB, MB, GB, or TB, respectively).<br /> * GRES-related arguments:<br /> ** &lt;code&gt;--gres&lt;/code&gt;, &lt;code&gt;--and-gres&lt;/code&gt;: Only include nodes whose list of GRES contains ''all'' of the specified GRES type/quantity pairings.<br /> ** &lt;code&gt;--or-gres&lt;/code&gt;: Only include nodes whose list of GRES contains ''any'' of the specified GRES type/quantity pairings. Functionally identical to &lt;tt&gt;--and-gres&lt;/tt&gt; if only one GRES type/quantity pairing is specified.<br /> * GPU-related arguments:<br /> ** &lt;code&gt;--gpus&lt;/code&gt;, &lt;code&gt;--and-gpus&lt;/code&gt;: Only include nodes whose list of GPUs (a subset of GRES) contains ''all'' of the specified GPU type/quantity pairings.<br /> ** &lt;code&gt;--or-gpus&lt;/code&gt;: Only include nodes whose list of GPUs (a subset of GRES) contains ''any'' of the specified GPU type/quantity pairings. Functionally identical to &lt;tt&gt;--and-gpus&lt;/tt&gt; if only one GPU type/quantity pairing is specified.<br /> * Feature-related arguments:<br /> ** &lt;code&gt;--feature&lt;/code&gt;, &lt;code&gt;--and-feature&lt;/code&gt;: Only include nodes whose list of features contains ''all'' of the specified feature(s).<br /> ** &lt;code&gt;--or-feature&lt;/code&gt;: Only include nodes whose list of features contains ''any'' of the specified feature(s). Functionally identical to &lt;tt&gt;--and-feature&lt;/tt&gt; if only one feature is specified.<br /> <br /> These arguments are also viewable by running &lt;code&gt;show_available_nodes -h&lt;/code&gt;.<br /> <br /> If your passed argument set does not contain any resource-based arguments (CPUs/RAM/GRES or GPUs), a node is defined as available if it has at least 1 CPU and 1MB of RAM available.<br /> <br /> If there are no nodes available that meet your passed argument set, you will receive the message &lt;tt&gt;There are no nodes that have currently free resources that meet this argument set.&lt;/tt&gt;<br /> <br /> ===Footnotes===<br /> [0] - As of now, this command alias does not factor in resources occupied by jobs that could be preempted (based on the partition(s) passed to it, if present). This is something that we are working on implementing.<br /> <br /> [1] - This command alias also does not factor in jobs with higher priority values requesting more resources, in the same partition(s), blocking execution of a job submitted with the resources / other arguments checked by the command alias. This is due to the infeasibility of calculating a job's priority value before it is actually submitted.<br /> <br /> ===Examples===<br /> Show all available nodes:<br /> &lt;pre&gt;<br /> $ show_available_nodes<br /> brigid17<br /> cpus=16,mem=414593M<br /> brigid18<br /> cpus=8,mem=24875M<br /> ...<br /> &lt;/pre&gt;<br /> <br /> Show nodes available in the &lt;tt&gt;tron&lt;/tt&gt; partition:<br /> &lt;pre&gt;<br /> $ show_available_nodes --partition tron<br /> tron00<br /> cpus=14,mem=50433M,gres=gpu:rtxa6000:1<br /> tron01<br /> cpus=10,mem=17665M,gres=gpu:rtxa6000:2<br /> ...<br /> &lt;/pre&gt;<br /> <br /> Show nodes with one or more RTX A5000 or RTX A6000 GPUs available to the &lt;tt&gt;vulcan&lt;/tt&gt; account:<br /> &lt;pre&gt;<br /> $ show_available_nodes --account vulcan --or-gpus rtxa5000:1,rtxa6000:1<br /> vulcan32<br /> cpus=16,mem=193778M,gres=gpu:rtxa6000:4<br /> vulcan33<br /> cpus=15,mem=181499M,gres=gpu:rtxa5000:3<br /> ...<br /> &lt;/pre&gt;<br /> <br /> Show nodes with 4 or more CPUs, 48G or more memory, and one or more RTX A6000 GPUs available in the &lt;tt&gt;scavenger&lt;/tt&gt; partition:<br /> &lt;pre&gt;<br /> $ show_available_nodes --partition=scavenger --cpus=4 --mem=48g --or-gpus=rtxa6000:1<br /> cbcb27<br /> cpus=59,mem=218303M,gres=gpu:rtxa6000:6<br /> clip06<br /> cpus=20,mem=93448M,gres=gpu:rtxa6000:1<br /> ...<br /> &lt;/pre&gt;<br /> <br /> Show nodes with [https://en.wikipedia.org/wiki/Turing_(microarchitecture) Turing] or [https://en.wikipedia.org/wiki/Ampere_(microarchitecture) Ampere] architecture GPUs available in the &lt;tt&gt;scavenger&lt;/tt&gt; partition:<br /> &lt;pre&gt;<br /> $ show_available_nodes --partition=scavenger --or-feature=Ampere,Turing<br /> cbcb25<br /> cpus=24,mem=255278M,gres=gpu:rtx2080ti:1,gpu:gtx1080ti:1<br /> cbcb26<br /> cpus=127,mem=447707M,gres=gpu:rtxa5000:7<br /> ...<br /> &lt;/pre&gt;<br /> <br /> Show nodes with [https://en.wikipedia.org/wiki/Zen_(microarchitecture) Zen] architecture CPUs and [https://en.wikipedia.org/wiki/Ampere_(microarchitecture) Ampere] architecture GPUs available in the &lt;tt&gt;scavenger&lt;/tt&gt; partition:<br /> &lt;pre&gt;<br /> $ show_available_nodes --partition=scavenger --and-feature=Zen,Ampere<br /> cbcb26<br /> cpus=127,mem=447707M,gres=gpu:rtxa5000:7<br /> cbcb27<br /> cpus=59,mem=218303M,gres=gpu:rtxa6000:6<br /> ...<br /> &lt;/pre&gt;<br /> <br /> (bogus example) Attempt to show nodes available in the &lt;tt&gt;bogus&lt;/tt&gt; partition:<br /> &lt;pre&gt;<br /> $ show_available_nodes --partition=bogus<br /> There are no nodes that have currently free resources that meet this argument set.<br /> &lt;/pre&gt;<br /> <br /> =Requesting GPUs=<br /> If you need to do processing on a GPU, you will need to request that your job have access to GPUs just as you need to request processors or CPU cores. In SLURM, GPUs are considered &quot;generic resources&quot; also known as GRES. To request some number of GPUs be reserved/available for your job, you can use the flag &lt;code&gt;--gres=gpu:#&lt;/code&gt; (with the actual number of GPUs you want). If there are multiple types of GPUs available in the cluster and you need a specific type, you can provide the type option to the gres flag e.g. &lt;code&gt;--gres=gpu:rtxa5000:#&lt;/code&gt;. If you do not request a specific type of GPU, you are likely to be scheduled on an older, lower spec'd GPU.<br /> <br /> Note that some QoSes may have limits on the number of GPUs you can request per job, so you may need to specify a different QoS to request more GPUs.<br /> <br /> &lt;pre&gt;<br /> $ srun --pty --qos=medium --gres=gpu:2 nvidia-smi<br /> ...<br /> Wed Mar 6 16:59:39 2024<br /> +---------------------------------------------------------------------------------------+<br /> | NVIDIA-SMI 535.129.03 Driver Version: 535.129.03 CUDA Version: 12.2 |<br /> |-----------------------------------------+----------------------+----------------------+<br /> | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |<br /> | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |<br /> | | | MIG M. |<br /> |=========================================+======================+======================|<br /> | 0 NVIDIA GeForce RTX 2080 Ti Off | 00000000:3D:00.0 Off | N/A |<br /> | 32% 23C P8 1W / 250W | 0MiB / 11264MiB | 0% Default |<br /> | | | N/A |<br /> +-----------------------------------------+----------------------+----------------------+<br /> | 1 NVIDIA GeForce RTX 2080 Ti Off | 00000000:40:00.0 Off | N/A |<br /> | 32% 25C P8 1W / 250W | 0MiB / 11264MiB | 0% Default |<br /> | | | N/A |<br /> +-----------------------------------------+----------------------+----------------------+<br /> <br /> +---------------------------------------------------------------------------------------+<br /> | Processes: |<br /> | GPU GI CI PID Type Process name GPU Memory |<br /> | ID ID Usage |<br /> |=======================================================================================|<br /> | No running processes found |<br /> +---------------------------------------------------------------------------------------+<br /> &lt;/pre&gt;<br /> <br /> Please note that your job will only be able to see/access the GPUs you requested. If you only need 1 GPU, please only request 1 GPU. The others on the node (if any) will be left available for other users.<br /> <br /> &lt;pre&gt;<br /> $ srun --pty --gres=gpu:rtxa5000:1 nvidia-smi<br /> Thu Aug 25 15:22:15 2022<br /> +-----------------------------------------------------------------------------+<br /> | NVIDIA-SMI 470.129.06 Driver Version: 470.129.06 CUDA Version: 11.4 |<br /> |-------------------------------+----------------------+----------------------+<br /> | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |<br /> | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |<br /> | | | MIG M. |<br /> |===============================+======================+======================|<br /> | 0 NVIDIA RTX A5000 Off | 00000000:01:00.0 Off | Off |<br /> | 30% 23C P8 20W / 230W | 0MiB / 24256MiB | 0% Default |<br /> | | | N/A |<br /> +-------------------------------+----------------------+----------------------+<br /> <br /> +-----------------------------------------------------------------------------+<br /> | Processes: GPU Memory |<br /> | GPU PID Type Process name Usage |<br /> |=============================================================================|<br /> | No running processes found |<br /> +-----------------------------------------------------------------------------+<br /> &lt;/pre&gt;<br /> <br /> As with all other flags, the &lt;code&gt;--gres&lt;/code&gt; flag may also be passed to [[#sbatch | sbatch]] and [[#salloc | salloc]] rather than directly to [[#srun | srun]].<br /> <br /> =MPI example=<br /> To run [https://en.wikipedia.org/wiki/Message_Passing_Interface MPI] jobs, you will need to include the &lt;code&gt;--mpi=pmix&lt;/code&gt; flag in your submission arguments.<br /> <br /> &lt;pre&gt;<br /> #!/usr/bin/bash <br /> #SBATCH --job-name=mpi_test # Job name <br /> #SBATCH --nodes=4 # Number of nodes <br /> #SBATCH --ntasks=8 # Number of MPI ranks <br /> #SBATCH --ntasks-per-node=2 # Number of MPI ranks per node <br /> #SBATCH --ntasks-per-socket=1 # Number of tasks per processor socket on the node <br /> #SBATCH --time=00:30:00 # Time limit hrs:min:sec <br /> <br /> <br /> srun --mpi=pmix /nfshomes/username/testing/mpi/a.out <br /> &lt;/pre&gt;</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=SLURM/JobSubmission&diff=13366 2026-08-28T15:22:21Z

<p>Mbaney: </p> <hr /> <div>=Job Submission=<br /> SLURM offers a variety of ways to run jobs. It is important to understand the different options available and how to request the resources required for a job in order for it to run successfully. All job submission should be done from submit nodes; any computational code should be run in a job allocation on compute nodes. The following commands outline how to allocate resources on the compute nodes and submit processes to be run on the allocated nodes.<br /> <br /> The cluster that everyone with a [[Accounts#UMIACS_Account | UMIACS account]] has access to is [[Nexus]]. Please visit the Nexus page for instructions on how to connect to your assigned submit nodes.<br /> <br /> '''Computationally intensive processes run on submission nodes will be terminated. Please submit jobs to be scheduled on compute nodes for this purpose.'''<br /> <br /> For details on how SLURM decides how to schedule jobs when multiple jobs are waiting in a scheduler's queue, please see [[SLURM/Priority]].<br /> <br /> ==srun==<br /> The &lt;code&gt;srun&lt;/code&gt; command is used to run a process on the compute nodes in the cluster. If you pass it a normal shell command (or command that executes a script), it will submit a job to run that shell command/script on a compute node and then return. &lt;code&gt;srun&lt;/code&gt; accepts many command line options to specify the resources required by the command passed to it. Some common command line arguments are listed below and full documentation of all available options is available in the man page for &lt;code&gt;srun&lt;/code&gt;, which can be accessed by running &lt;code&gt;man srun&lt;/code&gt;.<br /> <br /> &lt;pre&gt;<br /> $ srun --qos=default --mem=100mb --time=1:00:00 bash -c 'echo &quot;Hello World from&quot; `hostname`'<br /> Hello World from tron33.umiacs.umd.edu<br /> &lt;/pre&gt;<br /> <br /> It is important to understand that &lt;code&gt;srun&lt;/code&gt; is an interactive command. By default input to &lt;code&gt;srun&lt;/code&gt; is broadcast to all compute nodes running your process and output from the compute nodes is redirected to &lt;code&gt;srun&lt;/code&gt;. This behavior can be changed; however, '''srun will always wait for the command passed to finish before exiting, so if you start a long running process and end your terminal session, your process will stop running on the compute nodes and your job will end'''. To run a non-interactive submission that will remain running after you logout, you will need to wrap your &lt;code&gt;srun&lt;/code&gt; commands in a batch script and submit it with [[#sbatch | sbatch]].<br /> <br /> ===Common srun Arguments===<br /> * &lt;code&gt;--job-name=&lt;JOBNAME&gt;&lt;/code&gt; ''Requests your job be named &lt;JOBNAME&gt;''<br /> * &lt;code&gt;--mem=1g&lt;/code&gt; ''Requests 1GB of memory for your job, if no unit is given MB is assumed''<br /> * &lt;code&gt;--ntasks=2&lt;/code&gt; ''Requests 2 &quot;tasks&quot; which map to cores on a CPU for your job; if passed to srun, runs the given command concurrently on each core''<br /> * &lt;code&gt;--cpus-per-task=2&lt;/code&gt; ''Requests 2 CPU cores be allocated per task for your job''<br /> * &lt;code&gt;--nodes=2&lt;/code&gt; ''Requests 2 nodes be allocated to your job; if passed to srun, runs the given command concurrently on each node''<br /> * &lt;code&gt;--nodelist=&lt;NODENAME&gt;&lt;/code&gt; ''Requests to run your job on the &lt;NODENAME&gt; node''<br /> * &lt;code&gt;--time=dd-hh:mm:ss&lt;/code&gt; ''Requests your job run for dd days, hh hours, mm minutes, and ss seconds''<br /> * &lt;code&gt;--error=&lt;ERRNAME&gt;&lt;/code&gt; ''Redirects stderr for your job to the &lt;ERRNAME&gt; file''<br /> * &lt;code&gt;--partition=&lt;PARTITIONNAME&gt;&lt;/code&gt; ''Requests your job run in the &lt;PARTITIONNAME&gt; partition''<br /> * &lt;code&gt;--qos=&lt;QOSNAME&gt;default&lt;/code&gt; ''Requests your job run with the &lt;QOSNAME&gt; QOS, to see the available QOS options on a cluster, run'' &lt;code&gt;show_qos&lt;/code&gt;<br /> * &lt;code&gt;--account=&lt;ACCOUNTNAME&gt;&lt;/code&gt; ''Requests your job runs under the &lt;ACCOUNTNAME&gt; Slurm account, different accounts have different available partitions/QOS''<br /> * &lt;code&gt;--output=&lt;OUTNAME&gt;&lt;/code&gt; ''Redirects stdout for your job to the &lt;OUTNAME&gt; file''<br /> * &lt;code&gt;--requeue&lt;/code&gt; ''Requests your job be automatically requeued if it is preempted''<br /> * &lt;code&gt;--exclusive&lt;/code&gt; ''Requests your job be the only one running on the node(s) it is assigned to. This requires that your job be allocated all of the resources on the node(s). The scheduler '''does not''' automatically give your job all of the node's/nodes' resources, however, so if you need more than the default, you still need to request these with'' &lt;code&gt;--ntasks&lt;/code&gt; ''and'' &lt;code&gt;--mem&lt;/code&gt;<br /> <br /> ===Interactive Shell Sessions===<br /> An interactive shell session on a compute node can be useful for debugging or developing code that isn't ready to be run as a batch job. To get an interactive shell on a node, use &lt;code&gt;srun&lt;/code&gt; with the &lt;code&gt;--pty&lt;/code&gt; argument to invoke a shell:<br /> &lt;pre&gt;<br /> $ srun --pty --qos=default --mem=1g --time=01:00:00 bash<br /> $ hostname<br /> tron33.umiacs.umd.edu<br /> &lt;/pre&gt;<br /> '''Please do not leave interactive shells running for long periods of time when you are not working. This blocks resources from being used by everyone else.'''<br /> <br /> ==salloc==<br /> The &lt;code&gt;salloc&lt;/code&gt; command can also be used to request resources be allocated without needing a batch script. Running salloc with a list of resources will allocate the resources you requested, create a job, and drop you into a subshell with the environment variables necessary to run commands in the newly created job allocation. When your time is up or you exit the subshell, your job allocation will be relinquished.<br /> <br /> &lt;pre&gt;<br /> $ salloc --qos=default -N 1 --mem=2g --time=01:00:00<br /> salloc: Granted job allocation 159<br /> $ srun /usr/bin/hostname<br /> tron33.umiacs.umd.edu<br /> $ exit<br /> exit<br /> salloc: Relinquishing job allocation 159<br /> &lt;/pre&gt;<br /> <br /> '''Please be careful when using salloc - any commands not invoked with srun will be run locally on the submission node.'''<br /> <br /> ==sbatch==<br /> The &lt;code&gt;sbatch&lt;/code&gt; command allows you to write a batch script to be submitted and run non-interactively on the compute nodes. To run a simple Hello World command on the compute nodes you could write a file, helloWorld.sh with the following contents:<br /> <br /> &lt;pre&gt;<br /> #!/bin/bash<br /> <br /> srun bash -c 'echo Hello World from `hostname`'<br /> &lt;/pre&gt;<br /> <br /> Then you need to submit the script with sbatch and request resources:<br /> <br /> &lt;pre&gt;<br /> $ sbatch --qos=default --mem=1g --time=1:00:00 helloWorld.sh<br /> Submitted batch job 121<br /> &lt;/pre&gt;<br /> <br /> SLURM will return a job number that you can use to check the status of your job with squeue:<br /> <br /> &lt;pre&gt;<br /> $ squeue<br /> JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)<br /> 121 tron helloWor username R 0:01 1 tron32<br /> &lt;/pre&gt;<br /> <br /> ====Advanced Batch Scripts====<br /> You can also write a batch script with all of your resources/options defined in the script itself. This is useful for jobs that need to be run tens/hundreds/thousands of times. You can then handle any necessary environment setup and run commands on the resources you requested by invoking commands with srun. The srun commands can also be more complex and be told to only use portions of your entire job allocation - each of these distinct srun commands makes up one &quot;job step&quot;. The batch script will be run on the first node allocated as part of your job allocation and each job step will be run on whatever resources you tell them to.<br /> <br /> In the following example, we have a batch job that will request 2 nodes in the cluster. We then load a specific version of [[Python]] into our environment and submit two job steps, each one using one node. Since srun blocks until the command finishes by default, we use the '&amp;' operator to background the process so that both job steps can run at once; however, this means that we then need to use the wait command to block processing until all background processes have finished.<br /> <br /> &lt;pre&gt;<br /> #!/bin/bash<br /> <br /> # Lines that begin with #SBATCH specify commands to be used by SLURM for scheduling. These MUST be above any non-#SBATCH lines in the script to take effect.<br /> <br /> #SBATCH --job-name=helloWorld # set job name<br /> #SBATCH --output=helloWorld.out.%j # indicates a file to redirect STDOUT to; %j is the jobid. If set, must be set to a file instead of a directory or else submission will fail.<br /> #SBATCH --error=helloWorld.err.%j # indicates a file to redirect STDERR to; %j is the jobid. If set, must be set to a file instead of a directory or else submission will fail.<br /> #SBATCH --time=00:05:00 # how long you would like your job to run; format=dd-hh:mm:ss<br /> #SBATCH --account=nexus # set account, this determines which partitions and QOSes are available for your job<br /> #SBATCH --partition=tron # set partition, this determines what nodes are available for your job<br /> #SBATCH --qos=default # set QOS, this determines how many resources can be requested within your job, and for how long<br /> #SBATCH --nodes=2 # number of nodes to allocate for your job<br /> #SBATCH --ntasks=4 # request 4 cpu cores be reserved for your job total<br /> #SBATCH --ntasks-per-node=2 # request 2 cpu cores be reserved per node<br /> #SBATCH --mem=1g # memory required by job; if unit is not specified MB will be assumed. for multi-node jobs, this argument allocates this much memory *per node*<br /> <br /> srun --nodes=1 --mem=512m bash -c &quot;hostname; python3 --version&quot; &amp; # use srun to invoke commands within your job; using an '&amp;'<br /> srun --nodes=1 --mem=512m bash -c &quot;hostname; python3 --version&quot; &amp; # will background the process allowing them to run concurrently<br /> wait # wait for any background processes to complete<br /> <br /> # Once the end of the batch script is reached, your job allocation will be revoked.<br /> &lt;/pre&gt;<br /> <br /> Another useful thing to know is that you can pass additional arguments into your sbatch scripts on the command line and reference them as &lt;code&gt;${1}&lt;/code&gt; for the first argument and so on.<br /> <br /> ====More Examples====<br /> * [[SLURM/ArrayJobs]]<br /> <br /> ==scancel==<br /> The &lt;code&gt;scancel&lt;/code&gt; command can be used to cancel your own job allocations or job steps that are no longer needed. It can be passed individual job IDs or an option to delete all of your jobs or jobs that meet certain criteria.<br /> *&lt;code&gt;scancel 255&lt;/code&gt; ''cancel job 255''<br /> *&lt;code&gt;scancel 255.3&lt;/code&gt; ''cancel job step 3 of job 255''<br /> *&lt;code&gt;scancel --user=username --partition=tron&lt;/code&gt; ''cancel all jobs for username in the tron partition; username must be your UMD directory ID''<br /> <br /> =Identifying Resources and Features=<br /> The &lt;code&gt;sinfo&lt;/code&gt; command can show you additional features of nodes in the cluster but you need to ask it to show some non-default options using a command like &lt;code&gt;sinfo -o &quot;%40N %8c %8m %35f %35G&quot;&lt;/code&gt;.<br /> <br /> &lt;pre&gt;<br /> $ sinfo -o &quot;%40N %10c %10m %40f %32G&quot;<br /> NODELIST CPUS MEMORY AVAIL_FEATURES GRES<br /> [root@nexusctl00 ~]# sinfo -o &quot;%40N %10c %10m %40f %32G&quot;<br /> NODELIST CPUS MEMORY AVAIL_FEATURES GRES<br /> cbcb[00-21] 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null)<br /> cbcb25 24 255278 rhel9,x86_64,Xeon,E5-2650,Pascal,Turing gpu:rtx2080ti:1,gpu:gtx1080ti:1<br /> cbcb30 48 1157583 rhel9,x86_64,EPYC,EPYC-9475F (null)<br /> legacy00 48 125940 rhel9,x86_64,Zen,EPYC-7402 (null)<br /> legacy[01-11,13-15,17-19] 12+ 126117+ rhel9,x86_64,Xeon,E5-2620 (null)<br /> legacy[20,42,50-51] 24+ 384270+ rhel9,x86_64,Xeon,E5-2680 (null)<br /> legacy[37-40] 64 512878 rhel9,x86_64,Zen,EPYC-7502 (null)<br /> legacy[33-36,43-44] 24 255150 rhel9,x86_64,Xeon,E5-2650 (null)<br /> legacy41 8 61567 rhel9,x86_64,Zen,EPYC-7262 (null)<br /> legacy45 44 1029404 rhel9,x86_64,Xeon,E5-2699 (null)<br /> legacy[46-49] 20 384271 rhel9,x86_64,Xeon,E5-2660 (null)<br /> legacy[52-53] 20 61739 rhel9,x86_64,Xeon,E5-2640 (null)<br /> cbcb26 128 513243 rhel9,x86_64,Zen,EPYC-7763,Ampere gpu:rtxa5000:7<br /> cbcb27 64 255167 rhel9,x86_64,Zen,EPYC-7513,Ampere gpu:rtxa6000:7<br /> cbcb[28-29] 32 771166 rhel9,x86_64,Zen,EPYC-9124,Ada gpu:rtx6000ada:8<br /> tron[46-61] 48 255225+ rhel9,x86_64,Zen,EPYC-7352,Ampere gpu:rtxa5000:8<br /> tron[06-09,12-15,21] 16 126214+ rhel9,x86_64,Zen,EPYC-7302P,Ampere gpu:rtxa4000:4<br /> tron[10-11,16-20,34] 16 126217 rhel9,x86_64,Zen,EPYC-7313P,Ampere gpu:rtxa4000:4<br /> tron[22-33,35-45] 16 126214+ rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa4000:4<br /> clip04 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtx3090:4<br /> clip11 16 126217 rhel9,x86_64,Zen,EPYC-7313,Ampere gpu:rtxa4000:4<br /> clip13,cml30,vulcan[29-32,45] 32 255218+ rhel9,x86_64,Zen,EPYC-7313,Ampere gpu:rtxa6000:8<br /> clip14 32 125964 rhel9,x86_64,Xeon,Gold-6226R,Ampere gpu:rtxa5000:3<br /> clip[05-06] 24 126216 rhel9,x86_64,Zen,EPYC-7352,Ampere gpu:rtxa6000:2<br /> cml[17-28],gammagpu05 32 255225+ rhel9,x86_64,Zen,EPYC-7282,Ampere gpu:rtxa4000:8<br /> cml33 64 1029019 rhel9,x86_64,Xeon,6448Y,Hopper gpu:h100-sxm:4<br /> cml38 128 2061422 rhel9,x86_64,Xeon,6776P,Blackwell gpu:b300-sxm:8<br /> cml31 32 384094 rhel9,x86_64,Zen,EPYC-9124,Ampere,Hopper gpu:a100:1,gpu:h100-nvl:1<br /> cml32 64 512999 rhel9,x86_64,Zen,EPYC-7543,Ampere gpu:a100:4<br /> cml37 16 383918 rhel9,x86_64,Zen,EPYC-9124,Blackwell gpu:rtx6000bw-mq:4<br /> cml[00,02-03,06-07,09-11,13-16],tron[62- 32 351530+ rhel9,x86_64,Xeon,4216,Turing gpu:rtx2080ti:8<br /> cml[04-05] 32 383030 rhel9,x86_64,Xeon,4216,Turing gpu:rtx2080ti:6<br /> cml08 32 383030 rhel9,x86_64,Xeon,4216,Turing gpu:rtx2080ti:7<br /> cml12 32 383038 rhel9,x86_64,Xeon,4216,Turing,Ampere gpu:rtx2080ti:7,gpu:rtxa4000:1<br /> cml34 32 513260 rhel9,x86_64,Zen,EPYC-7313,Ada gpu:l40s:8<br /> cml[35-36],vulcan46 128 2061187+ rhel9,x86_64,Xeon,8592+,Hopper gpu:h200-sxm:8<br /> gammagpu00 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa5000:8<br /> gammagpu[01-04,06-09],vulcan[33-37] 32 255170+ rhel9,x86_64,Zen,EPYC-7313,Ampere gpu:rtxa5000:8<br /> csd00,gammagpu[18-21] 32 254883 rhel9,x86_64,Xeon,6526Y,Ada gpu:l40s:4<br /> clip12,gammagpu[10-17] 16 126203+ rhel9,x86_64,Zen,EPYC-7313,Ampere gpu:rtxa6000:4<br /> oasis[00-12,14-36,38] 160 28114 rhel9,aarch64,Altra,Altra-80 (null)<br /> quics00 128 1545009 rhel9,x86_64,Zen,EPYC-9534 (null)<br /> tron[00,03] 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa6000:6<br /> vulcan24 16 126216 rhel9,x86_64,Zen,EPYC-7282,Ampere gpu:rtxa6000:4<br /> legacygpu06 20 255249 rhel9,x86_64,Xeon,E5-2699,Maxwell gpu:gtxtitanx:4<br /> tron[01-02] 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa6000:8<br /> tron[04-05] 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa6000:7<br /> vulcan[38-44] 32 255215 rhel9,x86_64,Zen,EPYC-7313,Ampere gpu:rtxa4000:8<br /> legacygpu00 20 255249 rhel9,x86_64,Xeon,E5-2650,Pascal gpu:titanxp:4<br /> legacygpu[02,07] 20 255249+ rhel9,x86_64,Xeon,E5-2650,Maxwell gpu:gtxtitanx:4<br /> legacygpu[03-04] 16 255268 rhel9,x86_64,Xeon,E5-2630,Maxwell gpu:gtxtitanx:2<br /> legacygpu05 44 513193 rhel9,x86_64,Xeon,E5-2699,Pascal gpu:gtx1080ti:4<br /> legacygpu09 32 255276 rhel9,x86_64,Xeon,E5-2683,Pascal gpu:titanxpascal:3<br /> legacygpu10 32 255276 rhel9,x86_64,Xeon,E5-2683,Pascal gpu:titanxpascal:1,gpu:titanxp:2<br /> legacygpu11 20 126255 rhel9,x86_64,Xeon,E5-2630,Pascal gpu:gtx1080ti:3<br /> legacygpu12 20 126243 rhel9,x86_64,Xeon,E5-2630,Pascal,Turing gpu:rtx2080ti:1,gpu:gtx1080ti:2<br /> legacygpu13 8 255263 rhel9,x86_64,Xeon,E5-2623,Pascal gpu:gtx1080ti:3<br /> legacygpu[14,26-41] 32 255258+ rhel9,x86_64,Xeon,E5-2683,Pascal gpu:gtx1080ti:8<br /> legacygpu15 32 383043 rhel9,x86_64,Xeon,6130,Pascal,Turing gpu:rtx2080ti:5,gpu:gtx1080ti:3<br /> legacygpu[16-17] 20 189498 rhel9,x86_64,Xeon,4114,Turing gpu:rtx2080ti:8<br /> legacygpu18 32 255259 rhel9,x86_64,Xeon,E5-2683,Pascal gpu:p6000:7,gpu:p100:1<br /> legacygpu[19,23] 32 255259 rhel9,x86_64,Xeon,E5-2683,Pascal gpu:p6000:7<br /> legacygpu[20-22,24-25] 32 255259 rhel9,x86_64,Xeon,E5-2683,Pascal gpu:p6000:8<br /> legacygpu42 24 770126 rhel9,x86_64,Xeon,6146,Pascal gpu:titanxp:10<br /> tron[64,67] 32 383028+ rhel9,x86_64,Xeon,4216,Turing,Ampere gpu:rtx2080ti:7,gpu:rtx3070:1<br /> brigid[16-17] 48 512897 rhel9,x86_64,Zen,EPYC-7443 (null)<br /> vulcan23 32 383030 rhel9,x86_64,Xeon,4612,Turing gpu:rtx2080ti:6<br /> vulcan[27-28] 56 770093 rhel9,x86_64,Xeon,8280,Turing gpu:rtx2080ti:10<br /> &lt;/pre&gt;<br /> <br /> Note that all of the nodes shown by this may not necessarily be in a partition you are able to submit to.<br /> <br /> You can identify further specific information about a node using [[SLURM/ClusterStatus#scontrol | scontrol]] with various flags.<br /> <br /> There are also two command aliases developed by UMIACS staff to show various node information in aggregate. They are &lt;code&gt;show_nodes&lt;/code&gt; and &lt;code&gt;show_available_nodes&lt;/code&gt;.<br /> <br /> ==show_nodes==<br /> The &lt;code&gt;show_nodes&lt;/code&gt; command alias shows each node's name, number of CPUs, memory, {OS, CPU architecture, CPU type, GPU architecture (if the node has GPUs)} (as AVAIL_FEATURES), GRES (GPUs), and State. It essentially wraps the &lt;tt&gt;sinfo&lt;/tt&gt; command with some pre-determined output format options and shows each node on its own line, in alphabetical order.<br /> <br /> To only view nodes in a specific partition, append &lt;code&gt;-p &lt;partition name&gt;&lt;/code&gt; to the command alias.<br /> <br /> ===Examples===<br /> &lt;pre&gt;<br /> $ show_nodes<br /> NODELIST CPUS MEMORY AVAIL_FEATURES GRES STATE<br /> brigid16 48 512897 rhel9,x86_64,Zen,EPYC-7443 (null) idle<br /> brigid17 48 512897 rhel9,x86_64,Zen,EPYC-7443 (null) idle<br /> ... ... ... ... ... ...<br /> vulcan45 32 513250 rhel9,x86_64,Zen,EPYC-7313,Ampere gpu:rtxa6000:8 idle<br /> &lt;/pre&gt;<br /> <br /> (specific partition)<br /> &lt;pre&gt;<br /> $ show_nodes -p tron<br /> NODELIST CPUS MEMORY AVAIL_FEATURES GRES STATE<br /> tron00 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa6000:8 idle<br /> tron01 32 255233 rhel9,x86_64,Zen,EPYC-7302,Ampere gpu:rtxa6000:8 idle<br /> ... ... ... ... ... ...<br /> tron69 32 383030 rhel9,x86_64,Xeon,4216,Turing gpu:rtx2080ti:8 idle<br /> &lt;/pre&gt;<br /> <br /> ==show_available_nodes==<br /> The &lt;code&gt;show_available_nodes&lt;/code&gt; command alias takes zero or more arguments that correspond to Slurm constructs, resources, or features that you are looking to request a job with and tells you what nodes could '''theoretically'''[0,1] run a job with these arguments immediately. It assumes your job is a single-node job.<br /> <br /> These arguments are:<br /> * &lt;code&gt;--partition&lt;/code&gt;: Only include nodes in the specified partition(s).<br /> * &lt;code&gt;--account&lt;/code&gt;: Only include nodes from partitions that can use the specified account(s).<br /> * &lt;code&gt;--qos&lt;/code&gt;: Only include nodes from partitions that can use the specified QoS(es).<br /> * &lt;code&gt;--cpus&lt;/code&gt;: Only include nodes with at least this many CPUs free.<br /> * &lt;code&gt;--mem&lt;/code&gt;: Only include nodes with at least this much memory free. The default unit is MB if unspecified, but any of {K,M,G,T} can be suffixed to the number provided (will then be interpreted as KB, MB, GB, or TB, respectively).<br /> * GRES-related arguments:<br /> ** &lt;code&gt;--gres&lt;/code&gt;, &lt;code&gt;--and-gres&lt;/code&gt;: Only include nodes whose list of GRES contains ''all'' of the specified GRES type/quantity pairings.<br /> ** &lt;code&gt;--or-gres&lt;/code&gt;: Only include nodes whose list of GRES contains ''any'' of the specified GRES type/quantity pairings. Functionally identical to &lt;tt&gt;--and-gres&lt;/tt&gt; if only one GRES type/quantity pairing is specified.<br /> * GPU-related arguments:<br /> ** &lt;code&gt;--gpus&lt;/code&gt;, &lt;code&gt;--and-gpus&lt;/code&gt;: Only include nodes whose list of GPUs (a subset of GRES) contains ''all'' of the specified GPU type/quantity pairings.<br /> ** &lt;code&gt;--or-gpus&lt;/code&gt;: Only include nodes whose list of GPUs (a subset of GRES) contains ''any'' of the specified GPU type/quantity pairings. Functionally identical to &lt;tt&gt;--and-gpus&lt;/tt&gt; if only one GPU type/quantity pairing is specified.<br /> * Feature-related arguments:<br /> ** &lt;code&gt;--feature&lt;/code&gt;, &lt;code&gt;--and-feature&lt;/code&gt;: Only include nodes whose list of features contains ''all'' of the specified feature(s).<br /> ** &lt;code&gt;--or-feature&lt;/code&gt;: Only include nodes whose list of features contains ''any'' of the specified feature(s). Functionally identical to &lt;tt&gt;--and-feature&lt;/tt&gt; if only one feature is specified.<br /> <br /> These arguments are also viewable by running &lt;code&gt;show_available_nodes -h&lt;/code&gt;.<br /> <br /> If your passed argument set does not contain any resource-based arguments (CPUs/RAM/GRES or GPUs), a node is defined as available if it has at least 1 CPU and 1MB of RAM available.<br /> <br /> If there are no nodes available that meet your passed argument set, you will receive the message &lt;tt&gt;There are no nodes that have currently free resources that meet this argument set.&lt;/tt&gt;<br /> <br /> ===Footnotes===<br /> [0] - As of now, this command alias does not factor in resources occupied by jobs that could be preempted (based on the partition(s) passed to it, if present). This is something that we are working on implementing.<br /> <br /> [1] - This command alias also does not factor in jobs with higher priority values requesting more resources, in the same partition(s), blocking execution of a job submitted with the resources / other arguments checked by the command alias. This is due to the infeasibility of calculating a job's priority value before it is actually submitted.<br /> <br /> ===Examples===<br /> Show all available nodes:<br /> &lt;pre&gt;<br /> $ show_available_nodes<br /> brigid17<br /> cpus=16,mem=414593M<br /> brigid18<br /> cpus=8,mem=24875M<br /> ...<br /> &lt;/pre&gt;<br /> <br /> Show nodes available in the &lt;tt&gt;tron&lt;/tt&gt; partition:<br /> &lt;pre&gt;<br /> $ show_available_nodes --partition tron<br /> tron00<br /> cpus=14,mem=50433M,gres=gpu:rtxa6000:1<br /> tron01<br /> cpus=10,mem=17665M,gres=gpu:rtxa6000:2<br /> ...<br /> &lt;/pre&gt;<br /> <br /> Show nodes with one or more RTX A5000 or RTX A6000 GPUs available to the &lt;tt&gt;vulcan&lt;/tt&gt; account:<br /> &lt;pre&gt;<br /> $ show_available_nodes --account vulcan --or-gpus rtxa5000:1,rtxa6000:1<br /> vulcan32<br /> cpus=16,mem=193778M,gres=gpu:rtxa6000:4<br /> vulcan33<br /> cpus=15,mem=181499M,gres=gpu:rtxa5000:3<br /> ...<br /> &lt;/pre&gt;<br /> <br /> Show nodes with 4 or more CPUs, 48G or more memory, and one or more RTX A6000 GPUs available in the &lt;tt&gt;scavenger&lt;/tt&gt; partition:<br /> &lt;pre&gt;<br /> $ show_available_nodes --partition=scavenger --cpus=4 --mem=48g --or-gpus=rtxa6000:1<br /> cbcb27<br /> cpus=59,mem=218303M,gres=gpu:rtxa6000:6<br /> clip06<br /> cpus=20,mem=93448M,gres=gpu:rtxa6000:1<br /> ...<br /> &lt;/pre&gt;<br /> <br /> Show nodes with [https://en.wikipedia.org/wiki/Turing_(microarchitecture) Turing] or [https://en.wikipedia.org/wiki/Ampere_(microarchitecture) Ampere] architecture GPUs available in the &lt;tt&gt;scavenger&lt;/tt&gt; partition:<br /> &lt;pre&gt;<br /> $ show_available_nodes --partition=scavenger --or-feature=Ampere,Turing<br /> cbcb25<br /> cpus=24,mem=255278M,gres=gpu:rtx2080ti:1,gpu:gtx1080ti:1<br /> cbcb26<br /> cpus=127,mem=447707M,gres=gpu:rtxa5000:7<br /> ...<br /> &lt;/pre&gt;<br /> <br /> Show nodes with [https://en.wikipedia.org/wiki/Zen_(microarchitecture) Zen] architecture CPUs and [https://en.wikipedia.org/wiki/Ampere_(microarchitecture) Ampere] architecture GPUs available in the &lt;tt&gt;scavenger&lt;/tt&gt; partition:<br /> &lt;pre&gt;<br /> $ show_available_nodes --partition=scavenger --and-feature=Zen,Ampere<br /> cbcb26<br /> cpus=127,mem=447707M,gres=gpu:rtxa5000:7<br /> cbcb27<br /> cpus=59,mem=218303M,gres=gpu:rtxa6000:6<br /> ...<br /> &lt;/pre&gt;<br /> <br /> (bogus example) Attempt to show nodes available in the &lt;tt&gt;bogus&lt;/tt&gt; partition:<br /> &lt;pre&gt;<br /> $ show_available_nodes --partition=bogus<br /> There are no nodes that have currently free resources that meet this argument set.<br /> &lt;/pre&gt;<br /> <br /> =Requesting GPUs=<br /> If you need to do processing on a GPU, you will need to request that your job have access to GPUs just as you need to request processors or CPU cores. In SLURM, GPUs are considered &quot;generic resources&quot; also known as GRES. To request some number of GPUs be reserved/available for your job, you can use the flag &lt;code&gt;--gres=gpu:#&lt;/code&gt; (with the actual number of GPUs you want). If there are multiple types of GPUs available in the cluster and you need a specific type, you can provide the type option to the gres flag e.g. &lt;code&gt;--gres=gpu:rtxa5000:#&lt;/code&gt;. If you do not request a specific type of GPU, you are likely to be scheduled on an older, lower spec'd GPU.<br /> <br /> Note that some QoSes may have limits on the number of GPUs you can request per job, so you may need to specify a different QoS to request more GPUs.<br /> <br /> &lt;pre&gt;<br /> $ srun --pty --qos=medium --gres=gpu:2 nvidia-smi<br /> ...<br /> Wed Mar 6 16:59:39 2024<br /> +---------------------------------------------------------------------------------------+<br /> | NVIDIA-SMI 535.129.03 Driver Version: 535.129.03 CUDA Version: 12.2 |<br /> |-----------------------------------------+----------------------+----------------------+<br /> | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |<br /> | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |<br /> | | | MIG M. |<br /> |=========================================+======================+======================|<br /> | 0 NVIDIA GeForce RTX 2080 Ti Off | 00000000:3D:00.0 Off | N/A |<br /> | 32% 23C P8 1W / 250W | 0MiB / 11264MiB | 0% Default |<br /> | | | N/A |<br /> +-----------------------------------------+----------------------+----------------------+<br /> | 1 NVIDIA GeForce RTX 2080 Ti Off | 00000000:40:00.0 Off | N/A |<br /> | 32% 25C P8 1W / 250W | 0MiB / 11264MiB | 0% Default |<br /> | | | N/A |<br /> +-----------------------------------------+----------------------+----------------------+<br /> <br /> +---------------------------------------------------------------------------------------+<br /> | Processes: |<br /> | GPU GI CI PID Type Process name GPU Memory |<br /> | ID ID Usage |<br /> |=======================================================================================|<br /> | No running processes found |<br /> +---------------------------------------------------------------------------------------+<br /> &lt;/pre&gt;<br /> <br /> Please note that your job will only be able to see/access the GPUs you requested. If you only need 1 GPU, please only request 1 GPU. The others on the node (if any) will be left available for other users.<br /> <br /> &lt;pre&gt;<br /> $ srun --pty --gres=gpu:rtxa5000:1 nvidia-smi<br /> Thu Aug 25 15:22:15 2022<br /> +-----------------------------------------------------------------------------+<br /> | NVIDIA-SMI 470.129.06 Driver Version: 470.129.06 CUDA Version: 11.4 |<br /> |-------------------------------+----------------------+----------------------+<br /> | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |<br /> | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |<br /> | | | MIG M. |<br /> |===============================+======================+======================|<br /> | 0 NVIDIA RTX A5000 Off | 00000000:01:00.0 Off | Off |<br /> | 30% 23C P8 20W / 230W | 0MiB / 24256MiB | 0% Default |<br /> | | | N/A |<br /> +-------------------------------+----------------------+----------------------+<br /> <br /> +-----------------------------------------------------------------------------+<br /> | Processes: GPU Memory |<br /> | GPU PID Type Process name Usage |<br /> |=============================================================================|<br /> | No running processes found |<br /> +-----------------------------------------------------------------------------+<br /> &lt;/pre&gt;<br /> <br /> As with all other flags, the &lt;code&gt;--gres&lt;/code&gt; flag may also be passed to [[#sbatch | sbatch]] and [[#salloc | salloc]] rather than directly to [[#srun | srun]].<br /> <br /> =MPI example=<br /> To run [https://en.wikipedia.org/wiki/Message_Passing_Interface MPI] jobs, you will need to include the &lt;code&gt;--mpi=pmix&lt;/code&gt; flag in your submission arguments.<br /> <br /> &lt;pre&gt;<br /> #!/usr/bin/bash <br /> #SBATCH --job-name=mpi_test # Job name <br /> #SBATCH --nodes=4 # Number of nodes <br /> #SBATCH --ntasks=8 # Number of MPI ranks <br /> #SBATCH --ntasks-per-node=2 # Number of MPI ranks per node <br /> #SBATCH --ntasks-per-socket=1 # Number of tasks per processor socket on the node <br /> #SBATCH --time=00:30:00 # Time limit hrs:min:sec <br /> <br /> <br /> srun --mpi=pmix /nfshomes/username/testing/mpi/a.out <br /> &lt;/pre&gt;</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=MonthlyMaintenanceWindow&diff=13365 2026-08-21T12:51:00Z

<p>Mbaney: </p> <hr /> <div>[[HelpDesk | UMIACS staff]] takes a monthly maintenance window to patch and reboot all UMIACS-supported hosts and services. This provides a way for staff to ensure security updates are installed and applied on the numerous different platforms and appliances that UMIACS runs.<br /> <br /> The window for each month is calculated by adding 9 days to [https://en.wikipedia.org/wiki/Patch_Tuesday Microsoft's Patch Tuesday] to allow for enough time to marshal patches released that month from Microsoft, Red Hat, Apple, and other OS and application vendors and have enough time to get systems prepared to reboot. This translates to the window being on the '''Thursday that occurs between the 17th and the 23rd (inclusive)''' of each month. The window lasts from '''5pm-8pm'''.<br /> <br /> [[Nexus]] will always have a reservation in place from 4:45pm-8pm on the day of the upcoming window to prevent jobs from being scheduled on compute nodes. The 15-minute addition before the start of the window is to allow jobs to fully end. Any job submitted before the reservation begins that has a time limit that would run into the reservation will be held until at least the end of the reservation - 8pm on the day of the window. This is to prevent issues with jobs failing to end properly causing delays in work we have scheduled during the window.<br /> <br /> A list of upcoming maintenance windows is as follows, with the next one in bold. Again, the window is on the '''Thursday that occurs between the 17th and the 23rd (inclusive)''' of each month, and lasts from '''5pm-8pm'''.<br /> <br /> <br /> * '''September 17th 2026'''<br /> * October 22nd 2026<br /> * November 19th 2026<br /> * December 17th 2026<br /> <br /> ==Archives==<br /> * January 17th 2013 - BEGIN time of 8pm-12am for this window through February 20th 2020<br /> * February 21st 2013<br /> * March 21st 2013<br /> * April 18th 2013<br /> * May 23rd 2013<br /> * June 20th 2013<br /> * July 18th 2013<br /> * August 22nd 2013<br /> * September 19th 2013<br /> * October 17th 2013<br /> * December 19th 2013<br /> * January 23rd 2014<br /> * February 20th 2014<br /> * March 20th 2014<br /> * April 17th 2014<br /> * May 22nd 2014<br /> * June 19th 2014<br /> * July 17th 2014<br /> * August 21st 2014<br /> * September 18th 2014<br /> * October 23rd 2014<br /> * November 20th 2014<br /> * December 18th 2014<br /> * January 22nd 2015<br /> * February 19th 2015<br /> * March 19th 2015<br /> * May 21st 2015<br /> * June 18th 2015<br /> * July 23rd 2015<br /> * August 20th 2015<br /> * September 17th 2015<br /> * October 22nd 2015<br /> * November 19th 2015<br /> * December 17th 2015<br /> * January 21st 2016<br /> * February 18th 2016<br /> * March 12th 2016 (Adjusted date for AVW power outage)<br /> * April 21st 2016<br /> * May 19th 2016<br /> * June 23rd 2016<br /> * July 21st 2016<br /> * August 18th 2016<br /> * September 22nd 2016<br /> * October 20th 2016<br /> * November 17th 2016<br /> * December 22nd 2016<br /> * January 19th 2017<br /> * February 23rd 2017<br /> * March 23rd 2017<br /> * April 20th 2017<br /> * May 18th 2017<br /> * June 22nd 2017<br /> * July 20th 2017<br /> * August 17th 2017<br /> * September 21st 2017<br /> * October 19th 2017<br /> * December 21st 2017<br /> * January 18th 2018<br /> * February 22nd 2018<br /> * March 22nd 2018<br /> * April 19th 2018<br /> * May 17th 2018<br /> * June 21st 2018<br /> * July 19th 2018<br /> * August 23rd 2018<br /> * September 20th 2018<br /> * October 18th 2018<br /> * December 20th 2018<br /> * January 24th 2019<br /> * February 21st 2019<br /> * April 18th 2019<br /> * May 23rd 2019<br /> * June 20th 2019<br /> * July 18th 2019<br /> * August 22nd 2019<br /> * September 19th 2019<br /> * October 17th 2019<br /> * November 21st 2019<br /> * December 19th 2019<br /> * January 23rd 2020<br /> * February 20th 2020<br /> * April 23rd 2020 - BEGIN time of 5pm-7pm for this window through August 19th 2021<br /> * June 18th 2020<br /> * July 23rd 2020<br /> * August 20th 2020<br /> * September 17th 2020<br /> * October 22nd 2020<br /> * November 19th 2020<br /> * December 17th 2020<br /> * January 21st 2021<br /> * February 18th 2021<br /> * March 25th 2021 (Adjusted date for extended Spring Break)<br /> * April 22nd 2021<br /> * May 20th 2021<br /> * June 17th 2021<br /> * July 22nd 2021<br /> * August 19th 2021<br /> * September 23rd 2021 - BEGIN time of 5pm-8pm for this window and all others below<br /> * October 21st 2021<br /> * November 18th 2021<br /> * January 20th 2022<br /> * February 17th 2022<br /> * March 24th 2022 (Adjusted date for Spring Break)<br /> * April 21st 2022<br /> * May 19th 2022<br /> * June 23rd 2022<br /> * July 21st 2022<br /> * August 18th 2022<br /> * September 22nd 2022<br /> * October 20th 2022<br /> * November 17th 2022<br /> * January 19th 2023<br /> * February 23rd 2023<br /> * April 20th 2023<br /> * May 18th 2023<br /> * June 22nd 2023<br /> * July 20th 2023<br /> * August 17th 2023<br /> * September 21st 2023<br /> * October 19th 2023<br /> * December 20th 2023 (Adjusted date for early Winter Break)<br /> * January 18th 2024<br /> * February 22nd 2024<br /> * March 21st 2024<br /> * April 18th 2024<br /> * May 23th 2024<br /> * June 20th 2024<br /> * July 18th 2024<br /> * August 22nd 2024<br /> * September 19th 2024<br /> * October 17th 2024<br /> * November 21st 2024<br /> * December 19th 2024<br /> * January 23rd 2025<br /> * February 20th 2025<br /> * March 20th 2025<br /> * April 17th 2025<br /> * May 22nd 2025<br /> * June 19th 2025<br /> * July 17th 2025<br /> * August 21st 2025<br /> * September 18th 2025<br /> * October 23rd 2025<br /> * November 20th 2025<br /> * December 18th 2025<br /> * January 22nd 2026<br /> * February 19th 2026<br /> * March 19th 2026<br /> * April 23rd 2026<br /> * May 28th 2026 (Adjusted date for CIO-imposed network change freeze)<br /> * June 18th 2026<br /> * July 23rd 2026<br /> * August 20th 2026</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=OBJ&diff=13362 2026-08-19T20:05:34Z

<p>Mbaney: /* Access Key and Secret Key */</p> <hr /> <div>= UMIACS Object Store =<br /> An object store is a web-based storage solution focused on reliability, scalability, and security. It is best suited for public content storage/distribution, archiving data, or secure data sharing between users. Our Object Store can be used through the [https://obj.umiacs.umd.edu/obj web interface], the command line [[UMobj]] utilities, third-party graphical [[S3Clients | clients]], and even programmatically using many popular programming languages. We support a subset of the Amazon Simple Storage Services [http://docs.aws.amazon.com/AmazonS3/latest/API/Welcome.html (S3) API], built around a technology called [http://ceph.com/ Ceph].<br /> <br /> All data in our Object Store is stored on hard drives located in a datacenter managed by [[HelpDesk | UMIACS Staff]].<br /> <br /> = Terminology =<br /> S3-like storage thinks in terms of buckets and keys. Keys are analogous to files. A bucket is simply a container to a set of keys. There is no actual hierarchy inside of a bucket, but the standard UNIX path separator, a forward slash (/) at the end of a Key name, is interpreted by many clients (including this web site and our UMobj utilities) as being a directory delimiter. This allows you to copy data from your local filesystems to your buckets through umobj or third-party clients. You may specify who has what types of access to your buckets via Access Control Lists (ACLs) at the bucket level or the individual key level.<br /> <br /> Your data is protected from individual machine failure via replication within the cluster. All data is checksummed in accordance with the Amazon S3 protocol to ensure that data in transit is valid before it is accepted by the cluster. However, there are no backups or snapshots of this data in the cluster, so '''if you delete a key or bucket in the Object Store, there is no way to restore that information'''.<br /> <br /> = Getting Started =<br /> Non-faculty UMIACS user accounts are allocated 50GB of storage, and faculty accounts are allocated 10TB. To get started, [https://obj.umiacs.umd.edu/obj log in] and you will be redirected to the initial help page. You can also find the link from our https://intranet.umiacs.umd.edu site as &quot;OBJbox Object Store&quot;.<br /> <br /> = Buckets =<br /> You can create and browse your buckets (containers that hold data) by visiting your [https://obj.umiacs.umd.edu/obj/buckets/ buckets] page. You can also set bucket-level Access Control Lists (ACLs) from this page. Bucket-level ACLs get implicitly inherited to all the keys within the bucket. However, individual keys can have additional specific ACLs applied for more granular control.<br /> <br /> Bucket names must be unique. When you create a bucket it will notify you if the name is already taken.<br /> <br /> = Keys (files) =<br /> After selecting a bucket, you will be able to create folders and upload files within that bucket. Listed files can be downloaded, deleted, or assigned a specific ACL by the key owner/creator.<br /> <br /> '''Please note: Local file system ownership and permissions, and special files (such as symlinks) can not be represented in the Object Store. We highly suggest that if you are securing data into the Object Store and need these to be faithfully maintained that you use a local archive tool (tar, zip, etc..) to collect the data and then upload the resulting archive file(s).'''<br /> <br /> = Hosting a Website in your Bucket =<br /> Please visit [[OBJ/WebHosting]] for more information.<br /> <br /> = Deleting Keys (files) =<br /> Within the web interface you can delete files one-by-one. If you want to remove a bunch of files, you will need to use a different client as described below.<br /> <br /> '''This is dangerous as there are no backups of files in the Object Store. Be careful to only delete the data you intend to delete.'''<br /> <br /> = Clients =<br /> There are several clients that can be used (sometimes with a limited set of features) on your desktop to gain access to the Object Store. All supported UMIACS systems running RHEL8 have a copy of our [https://gitlab.umiacs.umd.edu/staff/umobj/blob/master/README.md#umobj UMobj] utilities preinstalled which provide command line access to the Object Store. We also have an article in our wiki on [[S3Clients | third party clients]] that lists and explains the details. These clients need to be configured with your Access and Secret Keys as described below.<br /> <br /> = Access Key and Secret Key =<br /> You have one or more pairs of Access Keys and Secret Keys that are used as credentials to not expose your UMD passphrase when using the Object Store. These can be obtained by clicking on your [https://obj.umiacs.umd.edu/obj/user/ username] in the upper right-hand corner. You'll use these to identify and authenticate yourself to the Object Store.<br /> <br /> '''Please treat your Secret Key(s) with the same confidentiality as a passphrase and do not plaintext it over email or otherwise or share it with any other individuals.'''<br /> <br /> '''Note:''' Each Access Key and Secret Key are specific to a particular object store, so if you are accessing multiple object stores you may want to write the credentials for each to separate files and then source each file when you want to use the associated object store. Please [[HelpDesk | contact staff]] if you have any questions.<br /> <br /> = LabGroups =<br /> LabGroups allow a group of users to share data while avoiding the need for complex ACLs by maintaining group ownership. Designated LabGroup managers can grant granular access (read, write, full control, manager) to buckets owned by the LabGroup. All objects owned by a LabGroup count against the group's quota rather than an individual's. LabGroups can be navigated using the menu with your username in the top right corner of the page. '''Note:''' this will only appear if you are a member of at least one LabGroup. At this point, you can browse the Object Store as the LabGroup and obtain your unique Access Key and Secret Key pair using the instructions above. To switch to another LabGroup or back to your own buckets, click the menu again and select the other group or your username.<br /> <br /> = Managing LabGroups =<br /> LabGroups have many different levels of membership: '''Managers, FULL_CONTROL, READ/WRITE,''' and '''READ'''. Managers can add or remove LabGroup Members while every other access level cannot. If you hold the Manager role in a LabGroup, you can add and remove users using the [https://obj.umiacs.umd.edu/obj/labgroup/list/ Manage LabGroups] page, which is available under the Manage menu at the top of the page. After selecting a LabGroup, you can add users by typing their username into the search field and selecting a membership role.<br /> <br /> = Requesting a LabGroup =<br /> To request a LabGroup for your project, please [[HelpDesk | contact staff]].</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=UMobj&diff=13361 2026-08-19T20:01:40Z

<p>Mbaney: </p> <hr /> <div>{{Note|'''UMobj has been deprecated in favor of the MinIO Client. Please see [[MinIO_Client]].'''}} <br /> <br /> <br /> The UMobj suite of utilities provide command-line access to the [https://obj.umiacs.umd.edu/obj UMIACS Object Store]. UMobj is preinstalled on all UMIACS-supported RHEL8 machines. For other operating systems or non UMIACS-supported hosts, we encourage use of one of the many [[S3Clients#Command_Line_Clients | third-party command line clients]] that exist.<br /> <br /> ==When to use UMobj==<br /> Use umobj if:<br /> * You are using a UMIACS-supported RHEL8 machine<br /> * You have a large number of files to upload (hundreds or thousands of files)<br /> * You are uploading large files (files greater than 4GB in size)<br /> <br /> ==Setup==<br /> We highly recommend setting a few environmental variables containing your credentials for<br /> convenience. When logged into the Object Store web interface (see list above), you can<br /> find these credentials on the user page. E.g. https://obj.umiacs.umd.edu/obj/user/<br /> <br /> For example, if you use the &lt;tt&gt;bash&lt;/tt&gt; shell, you can add something like the following to your<br /> &lt;tt&gt;.bashrc&lt;/tt&gt; or &lt;tt&gt;.bash_profile&lt;/tt&gt;.<br /> <br /> &lt;pre&gt;<br /> export OBJ_ACCESS_KEY_ID=&quot;&lt;ACCESS_KEY&gt;&quot;<br /> export OBJ_SECRET_ACCESS_KEY=&quot;&lt;SECRET_KEY&gt;&quot;<br /> export OBJ_SERVER=&quot;obj.umiacs.umd.edu&quot;<br /> &lt;/pre&gt;<br /> <br /> Or, in tcsh, you can do the following or add it into your &lt;tt&gt;.tcshrc&lt;/tt&gt;.<br /> <br /> &lt;pre&gt;<br /> setenv OBJ_ACCESS_KEY_ID &quot;&lt;ACCESS_KEY&gt;&quot;<br /> setenv OBJ_SECRET_ACCESS_KEY &quot;&lt;SECRET_KEY&gt;&quot;<br /> setenv OBJ_SERVER &quot;obj.umiacs.umd.edu&quot;<br /> &lt;/pre&gt;<br /> <br /> (substituting in your actual &lt;ACCESS_KEY&gt; and &lt;SECRET_KEY&gt; for your personal account or [[OBJ#LabGroups | LabGroup]] in the [https://obj.umiacs.umd.edu/obj/user/ Object Store]).<br /> <br /> ==Detailed Usage==<br /> For an example of how to use UMobj, please see [[UMobj/Example]].<br /> <br /> For complete usage information, please see the [[GitLab]] page for [https://gitlab.umiacs.umd.edu/staff/umobj/blob/master/README.md#umobj umobj].</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=Nexus&diff=13339 2026-08-12T15:29:20Z

<p>Mbaney: </p> <hr /> <div>{{Note|All Nexus cluster nodes have been upgraded from RHEL8 to RHEL9 as of 08/06/2026. Please see [[Nexus/ClusterOSUpgrade]] for more information.}}<br /> <br /> The Nexus is the combined scheduler of resources in UMIACS. The resource manager for Nexus is [[SLURM]]. Resources are arranged into partitions where users are able to schedule computational jobs. Users are arranged into a number of SLURM accounts based on faculty, lab, or center investments.<br /> <br /> = Getting Started =<br /> All accounts in UMIACS are sponsored. If you don't already have a UMIACS account, please see [[Accounts]] for information on getting one. You need a full UMIACS account - not a [[Accounts/Collaborator | collaborator account]] - in order to access Nexus.<br /> <br /> == Access ==<br /> Your access to submission nodes (alternatively called login nodes) for Nexus computational resources is determined by your account sponsor's department, center, or lab affiliation. You can log into the [https://intranet.umiacs.umd.edu/directory/cr/ UMIACS Directory CR application] and select the Computational Resource (CR) in the list that has the prefix &lt;code&gt;nexus&lt;/code&gt;. The Hosts section lists your available submission nodes - generally a pair of nodes with hostnames of the format &lt;tt&gt;nexus&lt;department, lab, or center abbreviation&gt;[00,01]&lt;/tt&gt;, e.g., &lt;tt&gt;nexusgroup00&lt;/tt&gt; and &lt;tt&gt;nexusgroup01&lt;/tt&gt;.<br /> <br /> Once you have identified your submission nodes, you can [[SSH]] into them [https://itsupport.umd.edu/itsupport?id=kb_article_view&amp;sysparm_article=KB0016076 after connecting to UMD's GlobalProtect VPN]. From there, you are able to submit to the cluster via our [[SLURM]] workload manager. You need to make sure that your submitted jobs have the correct account, partition, and qos.<br /> <br /> Please read our [[Nexus/Submission_Node_Policy|Submission Node Policy]] for guidance on appropriate usage of a submission node. If a submission node becomes unresponsive due to disregarding this policy, &lt;b&gt;we may kill user processes on these nodes to resolve the issue&lt;/b&gt;. We reserve the right to take action on users who repeatedly cause issues on submission nodes.<br /> <br /> == Jobs ==<br /> [[SLURM]] jobs are [[SLURM/JobSubmission | submitted]] by either &lt;code&gt;srun&lt;/code&gt; or &lt;code&gt;sbatch&lt;/code&gt; depending if you are doing an interactive job or batch job, respectively. You need to provide the where/how/who to run the job and specify the resources you need to run with.<br /> <br /> For the who/where/how, you may be required to specify &lt;code&gt;--account&lt;/code&gt;, &lt;code&gt;--partition&lt;/code&gt;, and/or &lt;code&gt;--qos&lt;/code&gt; (respectively) to be able to adequately submit jobs to the Nexus.<br /> <br /> For resources, you may need to specify &lt;code&gt;--time&lt;/code&gt; for time, &lt;code&gt;--cpus-per-task&lt;/code&gt; for CPUs, &lt;code&gt;--mem&lt;/code&gt; for RAM, and &lt;code&gt;--gres=gpu&lt;/code&gt; for GPUs in your submission arguments to meet your requirements. There are defaults for all four; if you don't specify something, you will get the default value for that resource, which is minimal (e.g., by default, NO GPUs are included if you do not specify &lt;code&gt;--gres=gpu&lt;/code&gt;). For more information about submission flags for GPU resources, see [[SLURM/JobSubmission#Requesting_GPUs | here]]. You may also use &lt;code&gt;--ntasks&lt;/code&gt; to specify the number of parallel processes to run, with each task having its own set of the resources specified above. You can run &lt;code&gt;man srun&lt;/code&gt; on your submission node for a complete list of available submission arguments.<br /> <br /> For a list of available GPU types on Nexus and their specs, please see [[Nexus/GPUs]].<br /> <br /> For details on how the network for Nexus is architected, please see [[Nexus/Network]]. This can be important if you wish to optimize performance of your jobs.<br /> <br /> === Interactive ===<br /> Once logged into a submission node, you can run simple interactive jobs. If your session is interrupted from the submission node, the job will be killed. As such, we encourage use of a terminal multiplexer such as [[Tmux]].<br /> <br /> &lt;pre&gt;<br /> $ srun --pty --cpus-per-task=4 --mem=2gb --gres=gpu:1 bash<br /> srun: Job account was unset; set to user default of 'nexus'<br /> srun: Job partition was unset; set to cluster default of 'tron'<br /> srun: Job QoS was unset; set to association default of 'default'<br /> srun: Job time limit was unset; set to partition default of 60 minutes<br /> srun: job 1 queued and waiting for resources<br /> srun: job 1 has been allocated resources<br /> $ hostname<br /> tron62.umiacs.umd.edu<br /> $ nvidia-smi -L<br /> GPU 0: NVIDIA GeForce RTX 2080 Ti (UUID: GPU-daad6a04-a2ce-1183-ce53-b267048f750a)<br /> &lt;/pre&gt;<br /> <br /> === Batch ===<br /> Batch jobs are scheduled with a script file with an optional ability to embed job scheduling parameters via variables that are defined by &lt;code&gt;#SBATCH&lt;/code&gt; lines at the top of the file. You can find some examples in our [[SLURM/JobSubmission]] documentation.<br /> <br /> = Partitions = <br /> The SLURM resource manager uses partitions to act as job queues which can restrict size, time and user limits. The Nexus has a number of different partitions of resources. Different Centers, Labs, and Faculty are able to invest in computational resources that are restricted to approved users through these partitions.<br /> <br /> '''Partitions usable by all non-[[ClassAccounts |class account]] users:'''<br /> * [[Nexus/Tron]] - Pool of resources available to all non-class accounts sponsored by either UMIACS or CSD faculty.<br /> * Scavenger - [https://slurm.schedmd.com/preempt.html Preemption] partition that contains [https://en.wikipedia.org/wiki/X86-64 x86_64] architecture nodes from multiple other partitions. More resources are available to schedule simultaneously than in other partitions, however jobs are subject to preemption rules. You are responsible for ensuring your jobs handle this preemption correctly. The SLURM scheduler will simply restart a preempted job with the same submission arguments when it is available to run again. For an overview of things you can check within scripts to determine if your job was preempted/resumed, see [[SLURM/Preemption]].<br /> * Scavenger (aarch64) - Preemption partition identical in design to &lt;tt&gt;scavenger&lt;/tt&gt;, but only contains [https://en.wikipedia.org/wiki/AArch64 aarch64] architecture nodes.<br /> <br /> '''Partitions usable by [[ClassAccounts]]:'''<br /> * [[ClassAccounts#Cluster_Usage | Class]] - Pool of resources available to class accounts sponsored by either UMIACS or CSD faculty.<br /> <br /> '''Partitions usable by specific lab/center users:'''<br /> * [[Nexus/CBCB]] - CBCB lab pool available for CBCB lab members.<br /> * [[Nexus/CLIP]] - CLIP lab pool available for CLIP lab members.<br /> * [[Nexus/CML]] - CML lab pool available for CML lab members.<br /> * [[Nexus/GAMMA]] - GAMMA lab pool available for GAMMA lab members.<br /> * [[Nexus/MBRC]] - MBRC lab pool available for MBRC lab members.<br /> * [[Nexus/MC2]] - MC2 lab pool available for MC2 lab members.<br /> * [[Nexus/QuICS]] - QuICS lab pool available for QuICS lab members.<br /> * [[Nexus/Vulcan]] - Vulcan lab pool available for Vulcan lab members.<br /> <br /> You can view the partitions that you have access to by using the &lt;code&gt;show_partitions&lt;/code&gt; command. By default, the command will show only the partitions that are available to you.<br /> <br /> &lt;pre&gt;<br /> $ show_partitions<br /> Name AllowAccounts AllowQos MaxNodes Nodes<br /> ------------------------ ----------------------- ------------------------------ ----------- ---------------------------- <br /> scavenger scavenger scavenger UNLIMITED brigid[16-19] <br /> cbcb[00-29] <br /> clip[00-13] <br /> cml[00,02-13,15-28,30-33] <br /> gammagpu[00-21] <br /> legacy[00-11,13-28,30-36] <br /> legacygpu[00-07] <br /> quics00 <br /> tron[00-69] <br /> vulcan[00-45]<br /> ------------------------------------------------------------------------------------------------------------------------<br /> scavenger-aarch64 scavenger scavenger-aarch64 UNLIMITED oasis[00-39]<br /> ------------------------------------------------------------------------------------------------------------------------ <br /> tron nexus default UNLIMITED tron[00-69] <br /> high <br /> medium <br /> &lt;/pre&gt;<br /> <br /> If you want to see information for all of the partitions, including those that you do not have access to, you can use the &lt;code&gt;show_partitions --all&lt;/code&gt; command.<br /> <br /> &lt;pre&gt;<br /> $ show_partitions --all<br /> Name AllowAccounts AllowQos MaxNodes Nodes<br /> ------------------------ ----------------------- ------------------------------ ----------- ---------------------------- <br /> cbcb cbcb default UNLIMITED cbcb[00-20,22-29] <br /> medium legacy[00-11,13-28,30-36] <br /> high <br /> huge-long <br /> highmem <br /> ------------------------------------------------------------------------------------------------------------------------<br /> cbcb-heng cbcb-heng default UNLIMITED cbcb[26-29] <br /> medium <br /> high <br /> huge-long <br /> highmem <br /> ------------------------------------------------------------------------------------------------------------------------ <br /> cbcb-interactive cbcb interactive UNLIMITED cbcb21<br /> ...<br /> &lt;/pre&gt;<br /> <br /> = Quality of Service (QoS) =<br /> SLURM uses Quality of Service (QoS) both to provide limits on job sizes (termed by us as &quot;job QoS&quot;) as well as to limit resources used by all jobs running in a partition, either per user or per group (termed by us as &quot;partition QoS&quot;).<br /> <br /> === Job QoS ===<br /> Job QoS are used to provide limits on the size of job that you can run. You should try to allocate only the resources your job actually needs, as resources that each of your jobs schedules are counted against your [[SLURM/Priority#Fair-share | fair-share priority]] in the future.<br /> * default - Default job QoS. Limited to 4 CPU cores, 1 GPU, and 32GB RAM per job. The maximum wall time per job is 3 days.<br /> * medium - Limited to 8 CPU cores, 2 GPUs, and 64GB RAM per job. The maximum wall time per job is 2 days.<br /> * high - Limited to 16 CPU cores, 4 GPUs, and 128GB RAM per job. The maximum wall time per job is 1 day.<br /> * scavenger - No resource limits per job, only a maximum wall time per job of 3 days. You are responsible for ensuring your job requests multiple nodes if it requests resources beyond what any one node is capable of. 11% of the total resources available for each trackable resource type in the partition (CPUs/GPUs/RAM) is permitted simultaneously across all of your jobs running with this job QoS, enforced via the corresponding partition QoS (below) for the scavenger partition. This job QoS is paired one-to-one with the scavenger partition. To use this job QoS, include &lt;code&gt;--partition=scavenger&lt;/code&gt; and &lt;code&gt;--account=scavenger&lt;/code&gt; in your submission arguments. Do not include any job QoS argument other than &lt;code&gt;--qos=scavenger&lt;/code&gt; (optional) or submission will fail.<br /> * scavenger-aarch64 - No resource limits per job, only a maximum wall time per job of 3 days. You are responsible for ensuring your job requests multiple nodes if it requests resources beyond what any one node is capable of. This job QoS is paired one-to-one with the scavenger-aarch64 partition. To use this job QoS, include &lt;code&gt;--partition=scavenger-aarch64&lt;/code&gt;, &lt;code&gt;--account=scavenger&lt;/code&gt;, and &lt;code&gt;--qos=scavenger-aarch64&lt;/code&gt; in your submission arguments.<br /> <br /> You can display these job QoS from the command line using the &lt;code&gt;show_qos&lt;/code&gt; command. By default, the command will only show job QoS that you can access. The above five job QoS are the ones that everyone can access.<br /> <br /> &lt;pre&gt;<br /> $ show_qos<br /> Name MaxWall MaxTRES MaxJobsPU MaxTRESPU <br /> -------------------- ----------- ------------------------------ --------- ------------------------------ <br /> default 3-00:00:00 cpu=4,gres/gpu=1,mem=32G <br /> high 1-00:00:00 cpu=16,gres/gpu=4,mem=128G <br /> medium 2-00:00:00 cpu=8,gres/gpu=2,mem=64G <br /> scavenger 3-00:00:00 <br /> scavenger-aarch64 3-00:00:00 <br /> &lt;/pre&gt;<br /> <br /> If you want to see all job QoS, including those that you do not have access to, you can use the &lt;code&gt;show_qos --all&lt;/code&gt; command. <br /> <br /> &lt;pre&gt;<br /> $ show_qos --all<br /> Name MaxWall MaxTRES MaxJobsPU MaxTRESPU<br /> -------------------- ----------- ------------------------------ --------- ------------------------------<br /> cml-cpu 7-00:00:00 8<br /> cml-default 7-00:00:00 cpu=4,gres/gpu=1,mem=32G 2<br /> cml-high 1-12:00:00 cpu=16,gres/gpu=4,mem=128G 2<br /> cml-high_long 14-00:00:00 cpu=32,gres/gpu=8 8 gres/gpu=8<br /> cml-medium 3-00:00:00 cpu=8,gres/gpu=2,mem=64G 2<br /> cml-scavenger 3-00:00:00 gres/gpu=24<br /> cml-very_high 1-12:00:00 cpu=32,gres/gpu=8,mem=256G 8 gres/gpu=12<br /> default 3-00:00:00 cpu=4,gres/gpu=1,mem=32G<br /> gamma-huge-long 10-00:00:00 cpu=32,gres/gpu=16,mem=256G<br /> high 1-00:00:00 cpu=16,gres/gpu=4,mem=128G<br /> highmem 21-00:00:00 cpu=128,mem=2T<br /> huge-long 10-00:00:00 cpu=32,gres/gpu=8,mem=256G<br /> interactive 12:00:00 cpu=4,mem=128G<br /> medium 2-00:00:00 cpu=8,gres/gpu=2,mem=64G<br /> oasis-exempt 10-00:00:00 cpu=160,mem=28114M<br /> scavenger 3-00:00:00<br /> scavenger-aarch64 3-00:00:00<br /> vulcan-cpu 2-00:00:00 cpu=1024,mem=4T 4<br /> vulcan-default 7-00:00:00 cpu=4,gres/gpu=1,mem=32G 2<br /> vulcan-exempt 7-00:00:00 cpu=32,gres/gpu=8,mem=256G 2<br /> vulcan-high 1-12:00:00 cpu=16,gres/gpu=4,mem=128G 2<br /> vulcan-high_long 14-00:00:00 cpu=32,gres/gpu=8 8 gres/gpu=8<br /> vulcan-medium 3-00:00:00 cpu=8,gres/gpu=2,mem=64G 2<br /> vulcan-sailon 3-00:00:00 cpu=32,gres/gpu=8,mem=256G gres/gpu=48<br /> vulcan-scavenger 3-00:00:00 cpu=32,gres/gpu=8,mem=256G<br /> vulcan-scavenger-mu+ 3-00:00:00 cpu=288,gres/gpu=72,mem=1152G<br /> &lt;/pre&gt;<br /> <br /> You are able to submit to any partition that is listed in the &lt;code&gt;show_partitions&lt;/code&gt; command. If you need to use an account other than the default account &lt;tt&gt;nexus&lt;/tt&gt;, you will need to specify it via the &lt;code&gt;--account&lt;/code&gt; submission argument.<br /> <br /> === Partition QoS ===<br /> Partition QoS are used to limit resources used by all jobs running in a partition, either per user (MaxTRESPU) or per group (GrpTRES).<br /> <br /> To view partition QoS, use the &lt;code&gt;show_partition_qos&lt;/code&gt; command.<br /> <br /> &lt;pre&gt;<br /> $ show_partition_qos<br /> Name MaxSubmitPU MaxTRESPU GrpTRES<br /> ------------------------- ----------- -------------------------------- --------------------<br /> scavenger-aarch64_part 500 <br /> scavenger_part 500 cpu=11%,gres/gpu=11%,mem=11% <br /> tron 500 cpu=32,gres/gpu=4,mem=262144M <br /> &lt;/pre&gt;<br /> <br /> The scavenger_part partition QoS has relative TRES limits based on the current hardware in a given partition, represented with percentages. To see the current actual TRES limits of this partition QoS, you can use the &lt;code&gt;-r/--real&lt;/code&gt; argument.<br /> <br /> &lt;pre&gt;<br /> $ show_partition_qos -r<br /> Name MaxSubmitPU MaxTRESPU GrpTRES<br /> ------------------------- ----------- -------------------------------- --------------------<br /> scavenger-aarch64_part 500 <br /> scavenger_part 500 cpu=888,gres/gpu=140,mem=12574G <br /> tron 500 cpu=32,gres/gpu=4,mem=262144M <br /> &lt;/pre&gt;<br /> <br /> If you want to see all partition QoS, including those that you do not have access to, you can use the &lt;code&gt;show_partition_qos --all&lt;/code&gt; command.<br /> <br /> &lt;pre&gt;<br /> $ show_partition_qos --all<br /> Name MaxSubmitPU MaxTRESPU GrpTRES<br /> ------------------------- ----------- -------------------------------- --------------------<br /> cbcb 500 cpu=1406,mem=50359G<br /> cbcb-heng 500 <br /> cbcb-interactive 500 <br /> class 500 cpu=32,gres/gpu=4,mem=262144M <br /> clip 500 cpu=726,mem=6939G<br /> cml 500 cpu=1226,mem=12116G<br /> cml-cpu 500 <br /> cml-director 500 <br /> cml-furongh 500 <br /> cml-scavenger 500 gres/gpu=24 <br /> cml-sfeizi 500 <br /> cml-wriva 500 <br /> cml-wriva-high 500 <br /> csd-h200 500 <br /> gamma 500 cpu=906,mem=7675G<br /> mbrc 500 cpu=370,mem=3571G<br /> mc2 500 cpu=330,mem=3201G<br /> oasis 500 <br /> quics 500 cpu=458,mem=4710G<br /> scavenger-aarch64_part 500 <br /> scavenger_part 500 cpu=11%,gres/gpu=11%,mem=11% <br /> tron 500 cpu=32,gres/gpu=4,mem=262144M <br /> vulcan 500 cpu=1402,mem=12936G<br /> vulcan-ampere 500 <br /> vulcan-cpu 500 <br /> vulcan-ramani 500 <br /> vulcan-scavenger 500 <br /> vulcan-scavenger-multi 500 <br /> &lt;/pre&gt;<br /> <br /> '''NOTE''': These QoS cannot be used directly when submitting jobs. Partition QoS limits apply to all jobs running on a given partition, regardless of what job QoS is used.<br /> <br /> For example, in the default non-preemption partition (&lt;tt&gt;tron&lt;/tt&gt;), you are restricted to 32 total CPU cores, 4 total GPUs, and 256GB total RAM at once across all jobs you have running in the partition.<br /> <br /> Lab/group-specific partitions may also have their own user limits, and/or may also have group limits on the total number of resources consumed simultaneously by all users that are using their partition, codified by the line in the output above that matches their lab/group name. Note that the values listed above in the two &quot;TRES&quot; columns are not fixed and may fluctuate per-partition as more resources are added to or removed from each partition.<br /> <br /> '''All partitions also only allow a maximum of 500 submitted (running (R) or pending (PD)) jobs per user in the partition simultaneously.''' This is to prevent excess pending jobs causing [https://slurm.schedmd.com/sched_config.html#backfill backfill] issues with the SLURM scheduler.<br /> * If you need to submit more than 500 jobs in batch at once, you can develop and run an &quot;outer submission script&quot; that repeatedly attempts to run an &quot;inner submission script&quot; (your original submission script) to submit jobs in the batch periodically, until all job submissions are successful. The outer submission script should use looping logic to check if you are at the max job limit and should then retry submission after waiting for some time interval.<br /> : An example outer submission script is as follows. In this example, &lt;code&gt;example_inner.sh&lt;/code&gt; is your inner submission script and is not an [[SLURM/ArrayJobs | array job]], and you want to run 1000 jobs. If your inner submission script is an array job, adjust the number of jobs accordingly. Array jobs must be of size 500 or less.<br /> &lt;pre&gt;<br /> #!/bin/bash<br /> numjobs=1000<br /> i=0<br /> while [ $i -lt $numjobs ]<br /> do<br /> while [[ &quot;$(sbatch example_inner.sh 2&gt;&amp;1)&quot; =~ &quot;QOSMaxSubmitJobPerUserLimit&quot; ]]<br /> do<br /> echo &quot;Currently at maximum job submissions allowed by the partition's QoS.&quot;<br /> echo &quot;Waiting for 5 minutes before trying to submit more jobs.&quot;<br /> sleep 300<br /> done<br /> i=$(( $i + 1 ))<br /> echo &quot;Submitted job $i of $numjobs&quot;<br /> done<br /> &lt;/pre&gt;<br /> <br /> It is suggested that you run the outer submission script in a [[Tmux]] session to keep the terminal window executing it from being interrupted.<br /> <br /> = Storage =<br /> All network storage available in Nexus is currently [[NFS]] based, and comes in a few different flavors. Compute nodes also have local scratch storage that can be used.<br /> <br /> == Home Directories ==<br /> {{Nfshomes}}<br /> <br /> == Scratch Directories ==<br /> Scratch data has no data protection including no snapshots and the data is not backed up. There are two types of scratch directories in the Nexus compute infrastructure:<br /> * Network scratch directories<br /> * Local scratch directories<br /> <br /> Please note that [[ClassAccounts | class accounts]] do not have network scratch directories.<br /> <br /> === Network Scratch Directories ===<br /> You are allocated 200GB of scratch space via NFS from &lt;code&gt;/fs/nexus-scratch/&lt;USERNAME&gt;&lt;/code&gt; where &lt;USERNAME&gt; is your UMIACS username. '''It is not backed up or protected in any way.''' This directory is '''[[Automounter | automounted]]'''; you will need to &lt;code&gt;cd&lt;/code&gt; into the directory or request/specify a fully qualified file path to access it.<br /> <br /> You can view your quota usage by running &lt;code&gt;df -h /fs/nexus-scratch/&lt;USERNAME&gt;&lt;/code&gt;.<br /> <br /> You may request a permanent increase of up to 400GB total space without any faculty approval by [[HelpDesk | contacting staff]]. If you need space beyond 400GB, you will need faculty approval and/or a [[#Project_Allocations | project allocation]] for this. If you choose to increase your scratch space beyond 400GB, the increased space is also subject to the 270 TB days limit mentioned in the project allocation section before we check back in for renewal. For example, if you request 1.4TB total space, you may have this for 270 days (1TB beyond the 400GB permanent increase). The amount increased beyond 400GB will also count against your faculty member's 20TB total storage limit mentioned below.<br /> <br /> This file system is available on all submission, data management, and computational nodes within the cluster.<br /> <br /> === Local Scratch Directories ===<br /> Each computational node that you can schedule compute jobs on also has one or more local scratch directories. These are always named &lt;code&gt;/scratch0&lt;/code&gt;, &lt;code&gt;/scratch1&lt;/code&gt;, etc. and '''are not backed up or protected in any way.''' These directories are almost always more performant than any other storage available to the job as they are mounted from disks directly attached to the compute node. However, you must stage your data within the confines of your job and extract the relevant resultant data elsewhere before the end of your job.<br /> <br /> These local scratch directories have a tmpwatch job which will '''delete unaccessed data after 90 days''', scheduled via maintenance jobs to run once a month during our [[MonthlyMaintenanceWindow | monthly maintenance windows]]. Please make sure you secure any resultant data you wish to keep from these directories at the end of your job.<br /> <br /> == Faculty Allocations ==<br /> Each faculty member can be allocated 1TB of permanent lab space upon request. We can also support grouping these individual allocations together into larger center, lab, or research group allocations if desired by the faculty. Please [[HelpDesk | contact staff]] to inquire.<br /> <br /> Lab space storage is fully protected. It has [[Snapshots | snapshots]] enabled and is [[NightlyBackups | backed up nightly]].<br /> <br /> == Project Allocations ==<br /> Project allocations are available per user for 270 TB days; you can have a 1TB allocation for up to 270 days, a 3TB allocation for 90 days, etc..<br /> <br /> A single faculty member can not have more than 20TB of project allocations across all of their sponsored accounts active simultaneously. Network scratch allocation space increases beyond the 400GB permanent maximum also have the increase count against this limit (i.e., a 1TB network scratch allocation would have 600GB counted towards this limit).<br /> <br /> Project storage is fully protected. It has [[Snapshots | snapshots]] enabled and is [[NightlyBackups | backed up nightly]].<br /> <br /> The maximum allocation length you can request is 540 days (500GB space) and the maximum storage space you can request is 9TB (30 day length).<br /> <br /> To request an allocation, please [[HelpDesk | contact staff]] with the faculty member(s) that the project is under involved in the conversation. Please include the following details:<br /> * Project Name (short)<br /> * Description<br /> * Size (1TB, 2TB, etc.)<br /> * Length in days (270 days, 135 days, etc.)<br /> * Other user(s) that need to access the allocation, if any<br /> <br /> These allocations are available via &lt;code&gt;/fs/nexus-projects/&lt;project name&gt;&lt;/code&gt;. '''Renewal is not guaranteed to be available due to limits on the amount of total storage.''' Near the end of the allocation period, staff will contact you and ask if you are still in need of the storage allocation. If renewal is available, you can renew for up to another 270 TB days with reapproval from the original faculty approver.<br /> * If you are no longer in need of the storage allocation, you will need to relocate all desired data within two weeks of the end of the allocation period. Staff will then remove the allocation.<br /> * If you do not respond to staff's request by the end of the allocation period, staff will make the allocation temporarily inaccessible.<br /> ** If you do respond asking for renewal but the original faculty approver does not respond within two weeks of the end of the allocation period, staff will also make the allocation temporarily inaccessible.<br /> ** If one month from the end of the allocation period is reached without both you and the faculty approver responding, staff will remove the allocation.<br /> <br /> == Datasets ==<br /> We have read-only dataset storage available at &lt;code&gt;/fs/nexus-datasets&lt;/code&gt;. If there are datasets that you would like to see curated and made available, please see [[Datasets | this page]].<br /> <br /> The list of Nexus datasets we currently host can be viewed [https://info.umiacs.umd.edu/datasets/list/?q=Nexus here].</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=SLURM/ClusterStatus&diff=13338 2026-08-12T13:38:20Z

<p>Mbaney: </p> <hr /> <div>=Cluster Status=<br /> SLURM offers a variety of tools to check the general status of nodes/partitions in a cluster.<br /> <br /> ==sinfo==<br /> The sinfo command will show you the status of partitions in the cluster, in alphabetical order. Passing the -N flag will show each node individually, also in alphabetical order.<br /> &lt;pre&gt;<br /> $ sinfo<br /> PARTITION AVAIL TIMELIMIT NODES STATE NODELIST<br /> cbcb up infinite 9 mix cbcb[00,03,22,26-28],legacy[00,10,20]<br /> cbcb up infinite 3 alloc cbcb[01-02,29]<br /> cbcb up infinite 49 idle cbcb[04-20,23-25],legacy[01-09,11,13-19,21-28,30-31,34-35]<br /> ...<br /> vulcan-scavenger up infinite 14 mix brigid[16-17],vulcan[23-25,27-30,32-33,36-37,45]<br /> vulcan-scavenger up infinite 1 alloc vulcan35<br /> vulcan-scavenger up infinite 34 idle brigid[18-19],vulcan[00-22,26,34,38-44]<br /> &lt;/pre&gt;<br /> <br /> &lt;pre&gt;<br /> $ sinfo -N<br /> NODELIST NODES PARTITION STATE<br /> brigid16 1 vulcan-cpu mix<br /> brigid16 1 scavenger mix<br /> brigid16 1 vulcan-dpart mix<br /> brigid16 1 vulcan-scavenger mix<br /> ...<br /> vulcan45 1 vulcan-ramani mix<br /> vulcan45 1 vulcan-scavenger mix<br /> vulcan45 1 scavenger mix<br /> &lt;/pre&gt;<br /> <br /> ==scontrol==<br /> The scontrol command can be used to view the status/configuration of the nodes in the cluster. If passed specific node name(s) only information about those node(s) will be displayed, otherwise all nodes will be listed. To specify multiple nodes, separate each node name by a comma (no spaces).<br /> &lt;pre&gt;<br /> $ scontrol show nodes tron05,tron13<br /> NodeName=tron05 Arch=x86_64 CoresPerSocket=16<br /> CPUAlloc=28 CPUTot=32 CPULoad=47.32<br /> AvailableFeatures=rhel9,x86_64,Zen,EPYC-7302,Ampere<br /> ActiveFeatures=rhel9,x86_64,Zen,EPYC-7302,Ampere<br /> Gres=gpu:rtxa6000:8<br /> NodeAddr=tron05 NodeHostName=tron05 Version=21.08.5<br /> OS=Linux 4.18.0-348.20.1.el8_5.x86_64 #1 SMP Tue Mar 8 12:56:54 EST 2022<br /> RealMemory=257538 AllocMem=157696 FreeMem=197620 Sockets=2 Boards=1<br /> State=MIXED ThreadsPerCore=1 TmpDisk=0 Weight=100 Owner=N/A MCS_label=N/A<br /> Partitions=scavenger,tron<br /> BootTime=2022-04-21T17:40:51 SlurmdStartTime=2022-04-21T18:00:56<br /> LastBusyTime=2022-04-22T11:21:16<br /> CfgTRES=cpu=32,mem=257538M,billing=346,gres/gpu=8,gres/gpu:rtxa6000=8<br /> AllocTRES=cpu=28,mem=154G,gres/gpu=7,gres/gpu:rtxa6000=7<br /> CapWatts=n/a<br /> CurrentWatts=0 AveWatts=0<br /> ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s<br /> <br /> NodeName=tron13 Arch=x86_64 CoresPerSocket=16<br /> CPUAlloc=1 CPUTot=16 CPULoad=8.41<br /> AvailableFeatures=rhel9,x86_64,Zen,EPYC-7302P,Ampere<br /> ActiveFeatures=rhel9,x86_64,Zen,EPYC-7302P,Ampere<br /> Gres=gpu:rtxa4000:4<br /> NodeAddr=tron13 NodeHostName=tron13 Version=21.08.5<br /> OS=Linux 4.18.0-348.20.1.el8_5.x86_64 #1 SMP Tue Mar 8 12:56:54 EST 2022<br /> RealMemory=128525 AllocMem=65536 FreeMem=33463 Sockets=1 Boards=1<br /> State=MIXED ThreadsPerCore=1 TmpDisk=0 Weight=10 Owner=N/A MCS_label=N/A<br /> Partitions=scavenger,tron<br /> BootTime=2022-04-21T17:40:46 SlurmdStartTime=2022-04-21T17:54:51<br /> LastBusyTime=2022-04-22T13:04:57<br /> CfgTRES=cpu=16,mem=128525M,billing=173,gres/gpu=4,gres/gpu:rtxa4000=4<br /> AllocTRES=cpu=1,mem=64G,gres/gpu=4,gres/gpu:rtxa4000=4<br /> CapWatts=n/a<br /> CurrentWatts=0 AveWatts=0<br /> ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s<br /> &lt;/pre&gt;<br /> <br /> ==sacctmgr==<br /> The sacctmgr command shows cluster accounting information. One of the helpful commands is to list the available QoSes. <br /> <br /> &lt;pre&gt;<br /> [root@nexusctl00 ~]# sacctmgr list qos format=Name%20,Priority,MaxWall,MaxJobsPU<br /> Name Priority MaxWall MaxJobsPU<br /> -------------------- ---------- ----------- ---------<br /> normal 0<br /> scavenger 0 3-00:00:00<br /> medium 0 2-00:00:00<br /> high 0 1-00:00:00<br /> default 0 3-00:00:00<br /> ...<br /> &lt;/pre&gt;<br /> <br /> ==slurm-web==<br /> Slurm-web is a web dashboard for our Slurm HPC cluster. It provides cluster statistics and Slurm information for the Nexus cluster.<br /> * URL: https://slurm-web.umiacs.umd.edu</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=Nexus/CBCB&diff=13337 2026-08-12T13:37:49Z

<p>Mbaney: </p> <hr /> <div>The compute nodes from [[CBCB]]'s previous standalone cluster have folded into [[Nexus]] as of mid 2023.<br /> <br /> The Nexus cluster already has a large pool of compute resources made possible through college-level funding for UMIACS and CSD faculty. Details on common nodes already in the cluster (Tron partition) can be found [[Nexus/Tron | here]].<br /> <br /> Please [[HelpDesk | contact staff]] with any questions or concerns.<br /> <br /> = Submission Nodes =<br /> You can [[SSH]] to &lt;code&gt;nexuscbcb.umiacs.umd.edu&lt;/code&gt; to log in to a submission node.<br /> <br /> If you store something in a local filesystem directory (/tmp, /scratch0) on one of the two submission nodes, you will need to connect to that same submission node to access it later. The actual submission nodes are:<br /> * &lt;code&gt;nexuscbcb00.umiacs.umd.edu&lt;/code&gt;<br /> * &lt;code&gt;nexuscbcb01.umiacs.umd.edu&lt;/code&gt;<br /> <br /> = Compute Nodes = <br /> All compute nodes in CBCB-owned partitions (see below section) owned by CBCB faculty are named in the format &lt;code&gt;cbcb##&lt;/code&gt;. The sets of nodes are:<br /> * 22 nodes that were purchased in October 2022 with center-wide funding: cbcb[00-21]<br /> * 1 node from the previous standalone CBCB cluster that moved in as of Summer 2023: cbcb25<br /> * 4 additional nodes purchased by Dr. Heng Huang: cbcb[26-29]<br /> * 1 additional node purchased by Dr. Mihai Pop: cbcb30<br /> <br /> {| class=&quot;wikitable sortable&quot;<br /> ! Nodenames<br /> ! Quantity<br /> ! CPU cores per node (CPUs)<br /> ! Memory per node (type)<br /> ! Filesystem storage per node (type/location)<br /> ! GPUs per node (type)<br /> |-<br /> |cbcb[00-21]<br /> |22<br /> |32 (Dual [https://www.amd.com/en/products/processors/server/epyc/7003-series/amd-epyc-7313.html AMD EPYC 7313])<br /> |~2TB (DDR4 3200MHz)<br /> |~350GB (SATA SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch0]]), ~2TB (NVMe SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch1]])<br /> |0<br /> |-<br /> |cbcb25<br /> |1<br /> |24 (Dual [https://www.intel.com/content/www/us/en/products/sku/91767/intel-xeon-processor-e52650-v4-30m-cache-2-20-ghz/specifications.html Intel Xeon E5-2650 v4])<br /> |~256GB (DDR4 2400MHz)<br /> |~1.4TB (SATA SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch0]])<br /> |2 (1x [https://www.nvidia.com/en-gb/geforce/graphics-cards/geforce-gtx-1080-ti/specifications/ NVIDIA GeForce GTX 1080 Ti], 1x [https://www.nvidia.com/en-us/geforce/graphics-cards/compare/?section=compare-20 NVIDIA GeForce RTX 2080 Ti])<br /> |-<br /> |cbcb26<br /> |1<br /> |128 (Dual [https://www.amd.com/en/products/processors/server/epyc/7003-series/amd-epyc-7763.html AMD EPYC 7763])<br /> |~512GB (DDR4 3200MHz)<br /> |~3.4TB (NVMe SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch0]]), ~14TB (NVMe SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch1]])<br /> |7 ([https://www.nvidia.com/en-us/design-visualization/rtx-a5000 NVIDIA RTX A5000])<br /> |-<br /> |cbcb27<br /> |1<br /> |64 (Dual [https://www.amd.com/en/products/processors/server/epyc/7003-series/amd-epyc-7513.html AMD EPYC 7513])<br /> |~256GB (DDR4 3200MHz)<br /> |~3.4TB (SATA SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch0]]), ~3.5TB (NVMe SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch1]])<br /> |8 ([https://www.nvidia.com/en-us/design-visualization/rtx-a6000 NVIDIA RTX A6000])<br /> |-<br /> |cbcb[28-29]<br /> |2<br /> |32 (Dual [https://www.amd.com/en/products/processors/server/epyc/4th-generation-9004-and-8004-series/amd-epyc-9124.html AMD EPYC 9124])<br /> |~768GB (DDR5 4800MHz)<br /> |~350GB (SATA SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch0]]), ~7TB (NVMe SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch1]])<br /> |8 ([https://www.nvidia.com/en-us/design-visualization/rtx-6000 NVIDIA RTX 6000 Ada Generation])<br /> |-<br /> |cbcb30<br /> |1<br /> |48 (Single [https://www.amd.com/en/products/processors/server/epyc/9005-series/amd-epyc-9475f.html AMD EPYC 9475F])<br /> |~1.15TB (DDR5 6400MHz)<br /> |~350GB (NVMe SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch0]]), ~10.5TB (NVMe SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch1]])<br /> |0<br /> |- class=&quot;sortbottom&quot;<br /> !Total<br /> |28<br /> |1032 (various)<br /> |~49TB (various)<br /> |~103TB (various)<br /> |33 (various)<br /> |}<br /> <br /> Here is the listing of nodes as shown by the Slurm alias &lt;code&gt;show_nodes&lt;/code&gt; (again, all nodes are named in the format &lt;code&gt;cbcb##&lt;/code&gt;):<br /> &lt;pre&gt;<br /> [root@nexusctl00 ~]# show_nodes | grep cbcb<br /> NODELIST CPUS MEMORY AVAIL_FEATURES GRES STATE<br /> cbcb00 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb01 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb02 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb03 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb04 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb05 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb06 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb07 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb08 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb09 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb10 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb11 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb12 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb13 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb14 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb15 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb16 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb17 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb18 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb19 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb20 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb21 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb25 24 255278 rhel9,x86_64,Xeon,E5-2650,Pascal,Turing gpu:rtx2080ti:1,gpu:gtx1080ti:1 idle<br /> cbcb26 128 513243 rhel9,x86_64,Zen,EPYC-7763,Ampere gpu:rtxa5000:7 idle<br /> cbcb27 64 255167 rhel9,x86_64,Zen,EPYC-7513,Ampere gpu:rtxa6000:7 idle<br /> cbcb28 32 771166 rhel9,x86_64,Zen,EPYC-9124,Ada gpu:rtx6000ada:8 idle<br /> cbcb29 32 771166 rhel9,x86_64,Zen,EPYC-9124,Ada gpu:rtx6000ada:8 idle<br /> cbcb30 48 1157583 rhel9,x86_64,EPYC,EPYC-9475F (null) idle<br /> &lt;/pre&gt;<br /> <br /> = Network =<br /> The network infrastructure supporting the CBCB partition consists of:<br /> # One pair of network switches connected to each other via dual 100GbE links for redundancy, serving the following compute nodes:<br /> #* cbcb[00-21,26-30]: Two 100GbE links per node, one to each switch in the pair (redundancy).<br /> # One pair of network switches connected to the above pair of network switches via four 40GbE links, one between every combination of switches across the two pairings for redundancy, and to each other via dual 10GbE links for redundancy.<br /> #* cbcb25: Two 10GbE links, one to each switch in the pair (redundancy).<br /> <br /> For a broader overview of the network infrastructure supporting the Nexus cluster, please see [[Nexus/Network]].<br /> <br /> = Partitions =<br /> There are two partitions available to general CBCB [[SLURM]] users. You must specify one of these two partitions when submitting your job.<br /> <br /> * '''cbcb''' - This is the default partition. Job allocations on all nodes except those also in the '''cbcb-heng''' partition are guaranteed.<br /> * '''cbcb-interactive''' - This is a partition that only allows interactive jobs; you cannot submit jobs via &lt;code&gt;sbatch&lt;/code&gt; to this partition. Job allocations are guaranteed.<br /> <br /> There is one additional partition available solely to Dr. Heng Huang's sponsored accounts.<br /> <br /> * '''cbcb-heng''' - This partition is for exclusive priority access to Dr. Huang's purchased GPU nodes. Job allocations are guaranteed.<br /> <br /> = QoS = <br /> CBCB users have access to all of the [[Nexus#Quality_of_Service_.28QoS.29 | standard job QoSes]] in the '''cbcb''' and '''cbcb-heng''' partitions using the &lt;code&gt;cbcb&lt;/code&gt; account.<br /> <br /> The additional job QoSes for the '''cbcb''' and '''cbcb-heng''' partitions specifically are:<br /> * &lt;code&gt;highmem&lt;/code&gt;: Allows for significantly increased memory to be allocated.<br /> * &lt;code&gt;huge-long&lt;/code&gt;: Allows for longer jobs using higher overall resources.<br /> <br /> Please note that the partition has a &lt;code&gt;GrpTRES&lt;/code&gt; limit of 100% of the available cores/RAM on the partition-specific nodes in aggregate plus 50% of the available cores/RAM on legacy## nodes in aggregate, so your job may need to wait if all available cores/RAM (or GPUs) are in use.<br /> <br /> The ''only'' allowed job QoS for the '''cbcb-interactive''' partition is:<br /> * &lt;code&gt;interactive&lt;/code&gt;: Allows for 4 CPU / 128G mem jobs up to 12 hours in length - can only be used via &lt;code&gt;srun&lt;/code&gt; or &lt;code&gt;salloc&lt;/code&gt;.<br /> <br /> = Jobs =<br /> You will need to specify &lt;code&gt;--partition=cbcb&lt;/code&gt; and &lt;code&gt;--account=cbcb&lt;/code&gt; to be able to submit jobs to the CBCB partition. <br /> <br /> &lt;pre&gt;<br /> [username@nexuscbcb00:~ ] $ srun --pty --ntasks=16 --mem=2000G --qos=highmem --partition=cbcb --account=cbcb --time 1-00:00:00 bash<br /> srun: job 218874 queued and waiting for resources<br /> srun: job 218874 has been allocated resources<br /> [username@cbcb00:~ ] $ scontrol show job 218874<br /> JobId=218874 JobName=bash<br /> UserId=username(1000) GroupId=username(21000) MCS_label=N/A<br /> Priority=897 Nice=0 Account=cbcb QOS=highmem<br /> JobState=RUNNING Reason=None Dependency=(null)<br /> Requeue=1 Restarts=0 BatchFlag=0 Reboot=0 ExitCode=0:0<br /> RunTime=00:00:06 TimeLimit=1-00:00:00 TimeMin=N/A<br /> SubmitTime=2022-11-18T11:13:56 EligibleTime=2022-11-18T11:13:56<br /> AccrueTime=2022-11-18T11:13:56<br /> StartTime=2022-11-18T11:13:56 EndTime=2022-11-19T11:13:56 Deadline=N/A<br /> PreemptEligibleTime=2022-11-18T11:13:56 PreemptTime=None<br /> SuspendTime=None SecsPreSuspend=0 LastSchedEval=2022-11-18T11:13:56 Scheduler=Main<br /> Partition=cbcb AllocNode:Sid=nexuscbcb00:25443<br /> ReqNodeList=(null) ExcNodeList=(null)<br /> NodeList=cbcb00<br /> BatchHost=cbcb00<br /> NumNodes=1 NumCPUs=16 NumTasks=16 CPUs/Task=1 ReqB:S:C:T=0:0:*:*<br /> TRES=cpu=16,mem=2000G,node=1,billing=2266<br /> Socks/Node=* NtasksPerN:B:S:C=0:0:*:* CoreSpec=*<br /> MinCPUsNode=1 MinMemoryNode=2000G MinTmpDiskNode=0<br /> Features=(null) DelayBoot=00:00:00<br /> OverSubscribe=OK Contiguous=0 Licenses=(null) Network=(null)<br /> Command=bash<br /> WorkDir=/nfshomes/username<br /> Power=<br /> &lt;/pre&gt;<br /> <br /> = Storage =<br /> CBCB still has its current [https://wiki.umiacs.umd.edu/cbcb-private/index.php/Storage storage] allocation in place. All data filesystems that were available in the standalone CBCB cluster are also available in Nexus. Please note about the change in your home directory in the migration section below.<br /> <br /> CBCB users can also request [[Nexus#Project_Allocations | Nexus project allocations]].<br /> <br /> = Operating System / Software =<br /> CBCB's standalone cluster submission and compute nodes were running RHEL7. [[Nexus]] is running RHEL9, so any software you compiled on the standalone cluster may need to be re-compiled to work correctly in this new environment. The [https://wiki.umiacs.umd.edu/cbcb/index.php/CBCB_Software_Modules CBCB module tree] for RHEL9+ may not yet be fully populated with RHEL9+ software. If you do not see the modules you need, please reach out to the [https://wiki.umiacs.umd.edu/cbcb/index.php/CBCB_Software_Modules#Contact CBCB software maintainers].</div>

Mbaney https://wiki.umiacs.umd.edu/umiacs/index.php?title=Nexus/CBCB&diff=13336 2026-08-12T13:36:57Z

<p>Mbaney: /* Compute Nodes */</p> <hr /> <div>The compute nodes from [[CBCB]]'s previous standalone cluster have folded into [[Nexus]] as of mid 2023.<br /> <br /> The Nexus cluster already has a large pool of compute resources made possible through college-level funding for UMIACS and CSD faculty. Details on common nodes already in the cluster (Tron partition) can be found [[Nexus/Tron | here]].<br /> <br /> Please [[HelpDesk | contact staff]] with any questions or concerns.<br /> <br /> = Submission Nodes =<br /> You can [[SSH]] to &lt;code&gt;nexuscbcb.umiacs.umd.edu&lt;/code&gt; to log in to a submission node.<br /> <br /> If you store something in a local filesystem directory (/tmp, /scratch0) on one of the two submission nodes, you will need to connect to that same submission node to access it later. The actual submission nodes are:<br /> * &lt;code&gt;nexuscbcb00.umiacs.umd.edu&lt;/code&gt;<br /> * &lt;code&gt;nexuscbcb01.umiacs.umd.edu&lt;/code&gt;<br /> <br /> = Compute Nodes = <br /> All compute nodes in CBCB-owned partitions (see below section) owned by CBCB faculty are named in the format &lt;code&gt;cbcb##&lt;/code&gt;. The sets of nodes are:<br /> * 22 nodes that were purchased in October 2022 with center-wide funding: cbcb[00-21]<br /> * 1 node from the previous standalone CBCB cluster that moved in as of Summer 2023: cbcb25<br /> * 4 additional nodes purchased by Dr. Heng Huang: cbcb[26-29]<br /> * 1 additional node purchased by Dr. Mihai Pop: cbcb30<br /> <br /> {| class=&quot;wikitable sortable&quot;<br /> ! Nodenames<br /> ! Quantity<br /> ! CPU cores per node (CPUs)<br /> ! Memory per node (type)<br /> ! Filesystem storage per node (type/location)<br /> ! GPUs per node (type)<br /> |-<br /> |cbcb[00-21]<br /> |22<br /> |32 (Dual [https://www.amd.com/en/products/processors/server/epyc/7003-series/amd-epyc-7313.html AMD EPYC 7313])<br /> |~2TB (DDR4 3200MHz)<br /> |~350GB (SATA SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch0]]), ~2TB (NVMe SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch1]])<br /> |0<br /> |-<br /> |cbcb25<br /> |1<br /> |24 (Dual [https://www.intel.com/content/www/us/en/products/sku/91767/intel-xeon-processor-e52650-v4-30m-cache-2-20-ghz/specifications.html Intel Xeon E5-2650 v4])<br /> |~256GB (DDR4 2400MHz)<br /> |~1.4TB (SATA SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch0]])<br /> |2 (1x [https://www.nvidia.com/en-gb/geforce/graphics-cards/geforce-gtx-1080-ti/specifications/ NVIDIA GeForce GTX 1080 Ti], 1x [https://www.nvidia.com/en-us/geforce/graphics-cards/compare/?section=compare-20 NVIDIA GeForce RTX 2080 Ti])<br /> |-<br /> |cbcb26<br /> |1<br /> |128 (Dual [https://www.amd.com/en/products/processors/server/epyc/7003-series/amd-epyc-7763.html AMD EPYC 7763])<br /> |~512GB (DDR4 3200MHz)<br /> |~3.4TB (NVMe SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch0]]), ~14TB (NVMe SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch1]])<br /> |7 ([https://www.nvidia.com/en-us/design-visualization/rtx-a5000 NVIDIA RTX A5000])<br /> |-<br /> |cbcb27<br /> |1<br /> |64 (Dual [https://www.amd.com/en/products/processors/server/epyc/7003-series/amd-epyc-7513.html AMD EPYC 7513])<br /> |~256GB (DDR4 3200MHz)<br /> |~3.4TB (SATA SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch0]]), ~3.5TB (NVMe SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch1]])<br /> |8 ([https://www.nvidia.com/en-us/design-visualization/rtx-a6000 NVIDIA RTX A6000])<br /> |-<br /> |cbcb[28-29]<br /> |2<br /> |32 (Dual [https://www.amd.com/en/products/processors/server/epyc/4th-generation-9004-and-8004-series/amd-epyc-9124.html AMD EPYC 9124])<br /> |~768GB (DDR5 4800MHz)<br /> |~350GB (SATA SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch0]]), ~7TB (NVMe SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch1]])<br /> |8 ([https://www.nvidia.com/en-us/design-visualization/rtx-6000 NVIDIA RTX 6000 Ada Generation])<br /> |-<br /> |cbcb30<br /> |1<br /> |48 (Single [https://www.amd.com/en/products/processors/server/epyc/9005-series/amd-epyc-9475f.html AMD EPYC 9475F])<br /> |~1.15TB (DDR5 6400MHz)<br /> |~350GB (NVMe SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch0]]), ~10.5TB (NVMe SSD [[FilesystemDataStorage#UNIX_Filesystem_Storage | /scratch1]])<br /> |0<br /> |- class=&quot;sortbottom&quot;<br /> !Total<br /> |28<br /> |1032 (various)<br /> |~49TB (various)<br /> |~103TB (various)<br /> |33 (various)<br /> |}<br /> <br /> Here is the listing of nodes as shown by the Slurm alias &lt;code&gt;show_nodes&lt;/code&gt; (again, all nodes are named in the format &lt;code&gt;cbcb##&lt;/code&gt;):<br /> &lt;pre&gt;<br /> [root@nexusctl00 ~]# show_nodes | grep cbcb<br /> NODELIST CPUS MEMORY AVAIL_FEATURES GRES STATE<br /> cbcb00 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb01 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb02 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb03 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb04 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb05 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb06 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb07 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb08 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb09 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb10 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb11 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb12 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb13 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb14 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb15 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb16 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb17 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb18 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb19 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb20 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb21 32 2061175 rhel9,x86_64,Zen,EPYC-7313 (null) idle<br /> cbcb25 24 255278 rhel9,x86_64,Xeon,E5-2650,Pascal,Turing gpu:rtx2080ti:1,gpu:gtx1080ti:1 idle<br /> cbcb26 128 513243 rhel9,x86_64,Zen,EPYC-7763,Ampere gpu:rtxa5000:7 idle<br /> cbcb27 64 255167 rhel9,x86_64,Zen,EPYC-7513,Ampere gpu:rtxa6000:7 idle<br /> cbcb28 32 771166 rhel9,x86_64,Zen,EPYC-9124,Ada gpu:rtx6000ada:8 idle<br /> cbcb29 32 771166 rhel9,x86_64,Zen,EPYC-9124,Ada gpu:rtx6000ada:8 idle<br /> cbcb30 48 1157583 rhel9,x86_64,EPYC,EPYC-9475F (null) idle<br /> &lt;/pre&gt;<br /> <br /> = Network =<br /> The network infrastructure supporting the CBCB partition consists of:<br /> # One pair of network switches connected to each other via dual 100GbE links for redundancy, serving the following compute nodes:<br /> #* cbcb[00-21,26-30]: Two 100GbE links per node, one to each switch in the pair (redundancy).<br /> # One pair of network switches connected to the above pair of network switches via four 40GbE links, one between every combination of switches across the two pairings for redundancy, and to each other via dual 10GbE links for redundancy.<br /> #* cbcb25: Two 10GbE links, one to each switch in the pair (redundancy).<br /> <br /> For a broader overview of the network infrastructure supporting the Nexus cluster, please see [[Nexus/Network]].<br /> <br /> = Partitions =<br /> There are two partitions available to general CBCB [[SLURM]] users. You must specify one of these two partitions when submitting your job.<br /> <br /> * '''cbcb''' - This is the default partition. Job allocations on all nodes except those also in the '''cbcb-heng''' partition are guaranteed.<br /> * '''cbcb-interactive''' - This is a partition that only allows interactive jobs; you cannot submit jobs via &lt;code&gt;sbatch&lt;/code&gt; to this partition. Job allocations are guaranteed.<br /> <br /> There is one additional partition available solely to Dr. Heng Huang's sponsored accounts.<br /> <br /> * '''cbcb-heng''' - This partition is for exclusive priority access to Dr. Huang's purchased GPU nodes. Job allocations are guaranteed.<br /> <br /> = QoS = <br /> CBCB users have access to all of the [[Nexus#Quality_of_Service_.28QoS.29 | standard job QoSes]] in the '''cbcb''' and '''cbcb-heng''' partitions using the &lt;code&gt;cbcb&lt;/code&gt; account.<br /> <br /> The additional job QoSes for the '''cbcb''' and '''cbcb-heng''' partitions specifically are:<br /> * &lt;code&gt;highmem&lt;/code&gt;: Allows for significantly increased memory to be allocated.<br /> * &lt;code&gt;huge-long&lt;/code&gt;: Allows for longer jobs using higher overall resources.<br /> <br /> Please note that the partition has a &lt;code&gt;GrpTRES&lt;/code&gt; limit of 100% of the available cores/RAM on the partition-specific nodes in aggregate plus 50% of the available cores/RAM on legacy## nodes in aggregate, so your job may need to wait if all available cores/RAM (or GPUs) are in use.<br /> <br /> The ''only'' allowed job QoS for the '''cbcb-interactive''' partition is:<br /> * &lt;code&gt;interactive&lt;/code&gt;: Allows for 4 CPU / 128G mem jobs up to 12 hours in length - can only be used via &lt;code&gt;srun&lt;/code&gt; or &lt;code&gt;salloc&lt;/code&gt;.<br /> <br /> = Jobs =<br /> You will need to specify &lt;code&gt;--partition=cbcb&lt;/code&gt; and &lt;code&gt;--account=cbcb&lt;/code&gt; to be able to submit jobs to the CBCB partition. <br /> <br /> &lt;pre&gt;<br /> [username@nexuscbcb00:~ ] $ srun --pty --ntasks=16 --mem=2000G --qos=highmem --partition=cbcb --account=cbcb --time 1-00:00:00 bash<br /> srun: job 218874 queued and waiting for resources<br /> srun: job 218874 has been allocated resources<br /> [username@cbcb00:~ ] $ scontrol show job 218874<br /> JobId=218874 JobName=bash<br /> UserId=username(1000) GroupId=username(21000) MCS_label=N/A<br /> Priority=897 Nice=0 Account=cbcb QOS=highmem<br /> JobState=RUNNING Reason=None Dependency=(null)<br /> Requeue=1 Restarts=0 BatchFlag=0 Reboot=0 ExitCode=0:0<br /> RunTime=00:00:06 TimeLimit=1-00:00:00 TimeMin=N/A<br /> SubmitTime=2022-11-18T11:13:56 EligibleTime=2022-11-18T11:13:56<br /> AccrueTime=2022-11-18T11:13:56<br /> StartTime=2022-11-18T11:13:56 EndTime=2022-11-19T11:13:56 Deadline=N/A<br /> PreemptEligibleTime=2022-11-18T11:13:56 PreemptTime=None<br /> SuspendTime=None SecsPreSuspend=0 LastSchedEval=2022-11-18T11:13:56 Scheduler=Main<br /> Partition=cbcb AllocNode:Sid=nexuscbcb00:25443<br /> ReqNodeList=(null) ExcNodeList=(null)<br /> NodeList=cbcb00<br /> BatchHost=cbcb00<br /> NumNodes=1 NumCPUs=16 NumTasks=16 CPUs/Task=1 ReqB:S:C:T=0:0:*:*<br /> TRES=cpu=16,mem=2000G,node=1,billing=2266<br /> Socks/Node=* NtasksPerN:B:S:C=0:0:*:* CoreSpec=*<br /> MinCPUsNode=1 MinMemoryNode=2000G MinTmpDiskNode=0<br /> Features=(null) DelayBoot=00:00:00<br /> OverSubscribe=OK Contiguous=0 Licenses=(null) Network=(null)<br /> Command=bash<br /> WorkDir=/nfshomes/username<br /> Power=<br /> &lt;/pre&gt;<br /> <br /> = Storage =<br /> CBCB still has its current [https://wiki.umiacs.umd.edu/cbcb-private/index.php/Storage storage] allocation in place. All data filesystems that were available in the standalone CBCB cluster are also available in Nexus. Please note about the change in your home directory in the migration section below.<br /> <br /> CBCB users can also request [[Nexus#Project_Allocations | Nexus project allocations]].<br /> <br /> = Operating System / Software =<br /> CBCB's standalone cluster submission and compute nodes were running RHEL7. [[Nexus]] is running a mixture of RHEL8 and RHEL9, so any software you compiled on the standalone cluster may need to be re-compiled to work correctly in this new environment. The [https://wiki.umiacs.umd.edu/cbcb/index.php/CBCB_Software_Modules CBCB module tree] for RHEL8+ may not yet be fully populated with RHEL8+ software. If you do not see the modules you need, please reach out to the [https://wiki.umiacs.umd.edu/cbcb/index.php/CBCB_Software_Modules#Contact CBCB software maintainers].</div>

Mbaney