Login Node Usage Policy

The login nodes are the shared front door to the RedRaider cluster. Hundreds of users work on the same few nodes at the same time, so one heavy process slows everyone down. This policy states what may run on the login nodes, where everything else must run, the limits that are enforced, and the regular updates that affect login sessions.

1. What may run on the login nodes

The login nodes are for preparing and managing work. They are not for doing the work itself.

Allowed

• Editing files and managing directories.
• Submitting, monitoring and canceling jobs (sbatch, squeue, scancel, interactive).
• Short tests that finish within a few minutes on one or two cores.
• Small, short builds. Please compile and build software on a compute node whenever you can.
  (see section 2).
• Installing packages into your own environment (conda, pip, R, Spack).
• Everything in this list is subject to the per-user limits in section 3.

Not allowed

• Running simulations, analysis, training, post-processing or any other computation. This applies to all software, including Python, R, MATLAB and scientific codes.
• Running AI agents of any kind, including AI coding agents such as Claude Code, Codex, GitHub Copilot agents, Cursor agents, Aider and similar tools.
• Large data transfers with scp, sftp or rsync (more than 1 GB per transfer or 2 GB per day). Please use Globus Service for those.
• Running the graphical interface of applications such as MATLAB, ANSYS, COMSOL or Jupyter on a login node.
• Leaving background processes, loops or services running after you log out.

• If you are not sure whether something belongs on a login node, it does not. Run it in a job.

List of programs and AI agents that are not allowed on login nodes

2. Where to run everything else

Everything in the "not allowed" list has a supported place to run.

sbatch

Batch jobs are the preferred way to work. A batch job keeps running when you log out, when your connection drops, and when a login node is rebooted.

Interactive sessions give you a shell on a compute node. The partition is required; the other options are optional:

interactive -p nocona -c 4 -t 02:00:00

• Use 

  interactive -h

   to see all options.
• An interactive session ends when its time limit is reached or when the login session that started it ends, so do not leave one running unattended. Use a batch job for anything that must run to completion.

Compiling on compute nodes. The partitions of the RedRaider cluster have different processors. Software built on a login node may run slower, or not at all, on the partition where you use it. Build it in an interactive session or a batch job on that partition, so that it is built for the processors it will run on.

Data transfers. Globus is the supported way to move data to and from HPCC storage. It is faster, restarts interrupted transfers by itself, and does not load the login nodes. Transfers made with scp, sftp or rsync through the login nodes may be stopped. See the file transfer guide.

AI agents. AI agents may be used on the RedRaider cluster only on compute nodes, and only in compliance with Texas Tech University policy. Start an interactive session and run the agent there, or use VS Code through Open OnDemand or CS-Bridge. In addition:

• You are responsible for everything an agent does under your account, including the jobs it submits and the files it changes.
• Texas Tech's IT policies apply to AI tools as they do to any other software:
  • OP 52.01, Information Technology Operations
  • OP 52.04, Information Technology Security.
  • TTU Prohibited Technologies
• Do not use confidential, sensitive or regulated data with any AI tool, and do not use AI models or agents that are prohibited by Texas Tech University policy or by state or federal law. This applies everywhere on the cluster, including compute nodes, and to external AI services.
• University-wide AI guidelines are being developed. Once published, they apply to all AI use on HPCC resources.

3. Limits on the login nodes

The following limits are enforced on every login node by an automated service. HPCC staff members do not monitor your sessions or decides case by case: the service measures usage and applies the same rules to everyone. They apply per user: all of your sessions and processes on one login node are counted together. Only HPCC staff are exempt.

scp

sftp

rsync

Sustained CPU use. Using about one full core continuously is treated as running a workload on the login node. It is handled in three steps:

1. After 15 minutes you receive a warning. Nothing is changed.
2. After 30 minutes your processes on that login node are slowed down. The slowdown lasts 30 minutes, until the 60-minute mark.
3. If it happens a second time within 24 hours, the processes that used the CPU are stopped.

What to expect:

• Everything is automated. A new monitoring system on the login nodes measures usage, applies these limits and sends the notices by itself. HPCC staff members do not monitor your sessions or decides who is slowed down or stopped, and the same rules apply to every user.
• You will be notified every time. Each action comes with a one-line notice on your terminal and an email to your TTU address. Both are sent by the automated service and are marked as automated. You get at most one email per program per day.
• Normal work is not affected. Editing files, submitting jobs and short builds stay well below these limits.
• Builds are better on compute nodes. Small, short builds are fine on a login node. Larger builds are limited to 2 cores there and will be warned after 15 minutes, so an interactive session or a batch job is faster and builds for the right processors.
• Stopped processes are not restarted. Unsaved work in a stopped process is lost. Move the work to a job before that point.
• Repeated misuse may lead HPCC staff to contact you, and to suspend your access if it continues.

4. Login node updates and reboots

The login nodes are updated twice a month to apply the latest security patches, and they are rebooted as part of each update.

• When: the night of the first and third Mondays of each month (the update starts at 11:15 PM; login nodes reboot one at a time between about 1 and 3 AM)
• One at a time. The login nodes are rebooted one after another, never all at once.
• You get a 5-minute warning on your terminal before the node you are on is rebooted.
• Everything on that login node ends: SSH sessions, tmux and screen sessions, editors, and interactive sessions that were started from it.
• Batch jobs are not affected. Running and queued batch jobs continue as usual.
• Log in again to  

  login.hpcc.ttu.edu

    or  

  quanah.hpcc.ttu.edu

    once the reboot is finished.

Urgent security patches. A high-priority security patch may have to be applied at any time and may require rebooting the login nodes outside this schedule. We give as much notice as the situation allows.

To avoid losing work, do not keep login sessions open for days, do not leave interactive sessions unattended, and submit long-running work as batch jobs.

Questions

Contact HPCC Support at hpccsupport@ttu.edu. We are glad to help you move a workflow from a login node into a batch job or an interactive session.