Computer Updates

Last updated: June 17, 2026

Keeping all computer systems up-to-date is an essential cornerstone of keeping them safe and secure, and is also required by university regulations. This guide explains how SCI keeps its machines (desktops and interactive servers) up to date via an automatic processes, and how users can have control over how it works.

NOTE:  any update cycle may require the host to be rebooted. When an update cycle is done, either manually or automatically, please make sure that you have saved all of your work so that no data will be lost as the result of a machine reboot.

Servers

Infrastructure

Infrastructure servers are machines that only SCI admins interact with directly, such as SCI’s web servers, file servers, etc.  These are set to update early in the morning, Monday through Friday, with various servers scheduled throughout the week to minimize service interruptions (either through a service being momentarily down or a bad update cascading across the infrastructure).  Generally, these should not really be noticed by most people, outside of the hosts in shell.sci.utah.edu (SCI’s internet-facing interactive hosts).

Compute Servers and Slurm

Any computer that is serving as a compute resource in Slurm is updated through a monthly, automated process. No running jobs are impacted by this process– when a particular machine is identified as needing to be updated, it will be put into a DRAIN mode, which means that no new jobs can be scheduled on it and any existing jobs are allowed to finish. Once all jobs have finished, the computer is patched and returned to service.  If you would like to schedule a job on a particular machine that is in DRAIN mode waiting for an update, feel free to do so and the regular processing of jobs will resume once the update has completed.

Interactive Machines

Windows/Apple User Computers

Windows and Apple devices that are not meant to be servers have their own built-in update mechanisms. It is left up to the user of those machines to configure the update cycle to mesh well with their personal preferences. Please keep in mind that the Internet is a dangerous place for unpatched machines, so please be judicious with maintaining your personal machines.

Linux Computers

Linux computers that are used for direct user access, including desktops and other research computers, are handled through an auto-update process where each machine identifies when an update is needed and then updates itself if so. There are three variables that control this:

  1. how long is “too long” since the machine was last patched (default: 30 days)
  2. when is an appropriate time to perform a system upgrade (default: Wednesday at 3am, MTZ)
  3. how much advanced warning users should be given before the update happens (default: 5 days)

The way it works is that each Linux machine in SCI, once a day, checks whether it’s been “too long” since the last package upgrade, and if so, it schedules an auto-update for the next suitable window (making sure that enough advance warning is given). Once an update is scheduled, a warning is displayed when logging into the machine, with additional Slack/email notifications being sent out (if configured for that machine). When the window arrives, the system upgrades the operating system and possibly reboots (if needed).

Note, you can always check the update status of a host by running the command update-localhost --check. For example:

[@yourmachine] ~ > update-localhost --check

Auto-update policy:
  Max age before auto-update: 30 days
  Min delay before scheduling: 5 days
  Preferred schedule: wednesday at 03:00

Current status:
Last upgrade: 2026-04-27 09:46:12 (9 days ago)

Reboot currently needed: no

Scheduled auto-update:
Host is up to date (21 days until auto-update)

[@yourmachine] ~ >

Notifications

When a linux host enters in to its auto-update cycle, it will notify users of the impending update through a variety of means.  The notifications happen:

  • when the update is first scheduled (usually a few days before the update happens)
  • the day before the update
  • when the update happens

These notifications happen via a console message sent to all active users of the system, and a banner will be displayed on login (via SSH) indicating that an update is forthcoming. The auto-update system can be configured to also send out notifications via email or Slack as well as the system notifications; seeTuning Auto-update Preferences for details.

What if the update comes at an inconvenient time?

With the advance notification, users should have plenty of warning before a system patches or reboots.  If the timing of this process is inconvenient for whatever reason, there are a couple of things you can do:

  • have a power user (see below) for that system preemptively update the machine, either by running an update cycle manually or scheduling one before the auto-update runs
  • contact SCI IT and have us work with you to find a good time for the system to be updated

Power Users

SCI IT can grant the ability for certain users to control the update cycle on a machine by giving them permissions to run the update-localhost and reboot-localhost commands, as well as edit the /local/etc/auto-update.conf file. Usually this is the owner of a Linux desktop system or a research group representative. If you feel that you should be a power user for a system, please contact your IT Liaison or SCI IT.

Tuning auto-update preferences

Power users can edit /local/etc/auto-update.conf to change when auto-updates run and how notifications are delivered. Simply use sudoedit — sudo opens the file in your preferred editor with the right privileges: sudoedit /local/etc/auto-update.conf.

Fields you can change:

  • UPDATE_DAY – preferred day of the week for updates (e.g., wednesday)
  • UPDATE_TIME – preferred time of day in 24-hour HH:MM format
  • REBOOT_AFTER_UPDATE – true or false — reboot after update if needed
  • NOTIFY_EMAIL – Comma-separated email addresses to also notify
  • NOTIFY_SLACK – Additional Slack channel(s) to also notify
  • MOTD_WARNING_DAYS –how many days before to show a warning (in motd) before a scheduled update

Changes take effect at the next daily scheduler check (typically midnight). Some limits (e.g., maximum allowed age between
updates) are set by SCI IT policy and can’t be loosened or made longer in the config file.

Running updates manually

Power users can also run update-localhost to update a host outside of the regular cycle (either immediately or scheduled in the future); this can be used to postpone the next auto-update or to just pick up new software updates if desired. Please run update-localhost --help for more details.

NOTE: an update cycle is not considered complete until all software updates have finished and the machine has been rebooted (if necessary, due to a new kernel or other reboot-requiring update). To make sure the system gets fully updated, please run update-localhostwith either the --reboot-if-needed or --reboot-forced option.