Linux Auto-Updates

Last updated: June 8, 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 IT keeps Linux hosts (desktops and interactive servers) up to date via an automatic process, 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.

Auto-updates

Auto-updates is a means by which Linux machines identify when an update is needed and then update themselves 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] ~ >

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.