Configure automatic Ubuntu security updates with controlled reboot windows
Apply Ubuntu security updates through reviewed origins, dry-run the exact unattended policy, schedule APT timers inside a declared maintenance window, and permit reboots only at a known local time when no users are logged in.
Reduce exposure to published Ubuntu vulnerabilities without turning package changes or reboots into invisible background risk: preserve recovery access, stage policy in lexically later drop-ins, verify timer calendars, observe a canary run, and retain a documented opt-out and rollback.
- Ubuntu Server 24.04 LTS
- unattended-upgrades 2.9.1
- systemd 255
- Recovery and maintenance ownership Keep console access, a tested backup, application owner approval, monitoring visibility, and a named operator for the first run and first reboot. Automatic updates are not a replacement for recovery.
- Supported repository trust Use Ubuntu archive and approved ESM repositories only for the initial policy. Inventory every PPA and third-party source separately; this guide does not automatically trust them.
apt-cache policy; grep -R --line-number '^URIs:\|^Suites:\|^Components:' /etc/apt/sources.list.d - Canary before fleet Select one representative noncritical host, prove service checks and reboot recovery there, then expand in waves. Do not enable simultaneous timers on an entire redundant tier.
- Stable timezone and window Set and document the host timezone before choosing {{rebootTime}} and timer calendars. Ubuntu passes the reboot time to `shutdown` in local system time.
timedatectl status
OneLiners never runs these steps or stores secrets. Review placeholders, versions, current state, and change-control requirements before using a command.
Full guide
What you will build
- An APT policy that refreshes indexes daily and automatically selects only Ubuntu and enabled ESM security origins.
- Explicit systemd timer windows that fetch metadata before installation and preserve missed runs without releasing an entire fleet simultaneously.
- A reboot gate that schedules a required reboot at {{rebootTime}} in local time but refuses to reboot while users are logged in.
- A canary workflow with dry-run evidence, package and service health checks, console recovery, and a staged fleet rollout.
- The merged APT configuration shows the exact intended origins and reboot controls, with no hidden third-party origin automatically trusted.
- Both APT timers show next occurrences inside the maintenance window and preserve their ordering after reboot.
- A dry-run names eligible security packages and exits cleanly before any real package state changes.
- The canary applies a real security update successfully, schedules or reports reboot state predictably, returns with no unexplained failed units, and exposes logs for audit.
Architecture
How the parts fit together
Ubuntu's APT periodic configuration decides whether package lists and unattended upgrades run, while systemd's `apt-daily` and `apt-daily-upgrade` timers decide when their services are activated. `unattended-upgrade` evaluates repository origin metadata and package policy, performs minimal package-manager steps, logs APT and dpkg activity, and creates or responds to the reboot-required marker. The reboot settings delegate a scheduled local-time shutdown only when configured conditions permit. Console, backups, monitoring, and a canary ring remain independent safety controls.
- The list-refresh timer starts apt-daily inside the first part of the maintenance window and downloads signed current metadata.
- The upgrade timer later starts apt-daily-upgrade, whose periodic policy invokes unattended-upgrade.
- unattended-upgrade matches packages against Ubuntu security and enabled ESM security origin patterns, respecting dpkg and APT state.
- Eligible packages are downloaded, unpacked, configured, and logged; failures leave explicit service, unattended, and dpkg evidence.
- If updated packages create `/var/run/reboot-required`, policy schedules shutdown at {{rebootTime}} only when no users are logged in.
- After boot, health checks, kernel/package evidence, timer schedules, and application monitoring determine whether the next rollout ring may proceed.
Assumptions
- The target is Ubuntu Server 24.04 LTS using supported Ubuntu archive repositories and systemd timers, not an immutable image that should be replaced rather than patched in place.
- The workload can tolerate package changes inside the declared window and has application-specific pre/post checks. Packages that require manual migrations are identified before automatic rollout.
- The host timezone is deliberate and synchronized. Operators understand that `Automatic-Reboot-Time` is interpreted in local host time.
- A provider, hypervisor, serial, or physical console works, backups are current, and a failed boot or package transaction can be recovered without SSH.
- The canary represents the production package set and kernel closely enough to expose meaningful regressions; the fleet is divided into staggered rings.
- Logged-in-user detection is a safety brake, not a complete maintenance coordinator. Services, jobs, clustered roles, and remote users still require explicit orchestration.
Key concepts
- Security pocket
- The Ubuntu repository suite carrying security fixes for a release, represented by origin/codename/label metadata evaluated by unattended-upgrades.
- APT periodic cadence
- A numeric day interval controlling whether periodic tasks are due; it does not itself guarantee a precise clock time.
- systemd timer calendar
- An `OnCalendar` expression that schedules the service wall-clock window, with persistence and randomized delay affecting actual activation.
- Origin pattern
- A structured match against repository metadata such as origin, codename, archive, and label; it is safer to review than trusting package names alone.
- Dry-run
- A simulated unattended-upgrade selection and action plan that does not install packages but reveals origins, candidates, holds, and policy errors.
- reboot-required
- Ubuntu's marker indicating that updated loaded components should be activated by reboot; its presence does not choose a safe business window.
- Canary ring
- A small representative set updated and observed before wider rings, limiting simultaneous exposure to a regression.
Before you copy
Values used in this guide
{{rebootTime}}Local host time passed to shutdown when an automatic reboot is required and no users are logged in.
Example: 04:45{{listRefreshCalendar}}systemd OnCalendar expression for package-list refresh, earlier than installation.
Example: Mon..Fri *-*-* 03:15{{upgradeCalendar}}systemd OnCalendar expression for unattended installation with enough time before reboot.
Example: Mon..Fri *-*-* 03:45Security and production boundaries
- Never disable repository signature checks or trust a third-party origin merely to make unattended updates succeed. Each external repository needs its own support, key-rotation, maintenance, and rollback decision.
- Automatic security updates reduce known-vulnerability exposure but can restart services during package configuration. Monitor application health and keep redundant roles staggered.
- Package blocklists can preserve a vulnerable component indefinitely. Every exception needs an owner, expiry, compensating control, and active tracking.
- Automatic reboot is a privileged availability action. Logged-in-user protection does not understand database primaries, batch work, quorum, or traffic drain; orchestrate those roles separately.
- Logs contain package inventory and failure context that may aid attackers. Restrict unattended and dpkg logs while retaining enough evidence for audit and incident response.
Stop before continuing if
- Stop if dpkg audit reports an interrupted transaction, another package manager is active, repository signatures fail, or disk space is insufficient.
- Do not enable automatic reboot without proven console recovery, backups, host timezone, application owner, and post-boot checks.
- Stop when the dry-run selects an unexpected origin, proposes package removals, exposes conffile prompts, or shows a package known to require manual migration.
- Do not roll beyond the canary when service health, boot, kernel, application checks, logs, or timer schedules are unexplained.
- Abort simultaneous fleet rollout when redundant nodes share the same randomized window or no capacity remains during a reboot.
verification
Inventory APT, holds, pending work, timers, and reboot state
Capture repositories, package-manager health, held packages, available security candidates, current timer schedules, logged-in users, service failures, and any existing reboot requirement before policy changes.
Why this step matters
Automation must begin from a healthy, attributable package state. Existing holds, failed units, users, timers, or reboot markers change what a first unattended run can safely do.
What to understand
`dpkg --audit` detects partially installed or inconsistent package state. Fix it under direct supervision before scheduling another package transaction.
Repository and hold inventory explains why candidates are eligible or excluded; timer inventory reveals whether automatic work already runs.
Record current logged-in users and failed services so post-update differences are attributable.
System changes
- No persistent change; reads package, timer, reboot, user, and service state.
Syntax explained
dpkg --audit- Reports packages that are unpacked or configured incompletely.
apt-mark showhold- Lists packages explicitly prevented from normal upgrade.
systemctl list-timers --all- Shows next and previous activation for both active and inactive timers.
/var/run/reboot-required.pkgs- Lists packages associated with the current reboot request when available.
sudo dpkg --audit; apt-mark showhold; apt-cache policy; systemctl list-timers apt-daily.timer apt-daily-upgrade.timer --all --no-pager; test -f /var/run/reboot-required && cat /var/run/reboot-required.pkgs || echo 'no reboot required'; systemctl --failed --no-pager; whoPackage files are OK NEXT LEFT LAST PASSED UNIT ACTIVATES Tue 2026-07-28 18:23:12 UTC 9h Tue 2026-07-28 06:14:02 UTC 2h ago apt-daily.timer apt-daily.service Wed 2026-07-29 06:11:44 UTC 21h Tue 2026-07-28 06:20:11 UTC 2h ago apt-daily-upgrade.timer apt-daily-upgrade.service no reboot required UNIT LOAD ACTIVE SUB DESCRIPTION 0 loaded units listed.
Checkpoint: Approve package baseline
Continue whendpkg is clean, repositories and holds are owned, no package process is active, console works, and failures/reboot state are understood.
Stop whenAny transaction, signature, disk, failed-unit, unknown hold, or pending-reboot issue remains.
If this step fails
dpkg audit reports packages only half configured.
Likely causeA prior update was interrupted by power, process kill, full disk, or a maintainer-script error.
ps -ef | grep -E '[a]pt|[d]pkg'sudo tail -n 100 /var/log/dpkg.logdf -h / /var
ResolutionConfirm no package process is active, fix capacity or the exact maintainer error, run `sudo dpkg --configure -a` under supervision, and repeat the baseline.
Security notes
- Repository URLs and package inventory may reveal internal services; protect the baseline record.
Alternatives
- Use signed fleet inventory that exposes the same effective repository and package state.
Stop conditions
- Never delete dpkg locks or start another package process to force progress.
command
Install and record unattended-upgrades from Ubuntu
Refresh signed indexes, inspect the candidate origin, install the package, and record its version. Package installation can enable default scheduling, so inspect timers immediately rather than assuming the system remains passive.
Why this step matters
The Ubuntu package supplies the maintained implementation, logs, and systemd integration; recording candidate origin prevents an unreviewed repository from silently becoming the update engine.
What to understand
`apt-cache policy` must show the expected Ubuntu archive candidate before installation.
Package installation can enable or preserve timers, so list them again immediately and do not assume scheduling waits for custom policy.
Use `apt-get` in scripted examples because Ubuntu documents it for noninteractive scripts.
System changes
- Installs unattended-upgrades and may enable packaged APT periodic behavior or units.
Syntax explained
apt-get update- Downloads and verifies current signed repository metadata.
apt-cache policy- Shows installed/candidate versions and their repository priorities.
apt-get install --yes- Installs the reviewed package noninteractively.
dpkg-query -W- Records the exact installed package version.
sudo apt-get update && apt-cache policy unattended-upgrades && sudo apt-get install --yes unattended-upgrades && dpkg-query -W -f='${Package} ${Version}\n' unattended-upgrades && systemctl list-timers apt-daily.timer apt-daily-upgrade.timer --all --no-pagerunattended-upgrades: Installed: 2.9.1+nmu4ubuntu1 Candidate: 2.9.1+nmu4ubuntu1 500 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages unattended-upgrades 2.9.1+nmu4ubuntu1 NEXT LEFT UNIT Tue 2026-07-28 18:23:12 UTC 9h apt-daily.timer Wed 2026-07-29 06:11:44 UTC 21h apt-daily-upgrade.timer
Checkpoint: Confirm supported package
Continue whenThe package comes from the intended Ubuntu release, version is recorded, and any active timers are known.
Stop whenCandidate origin is unexpected or a timer starts unreviewed work.
If this step fails
Installation reports unauthenticated packages.
Likely causeRepository signatures, keys, Release files, proxy, or clock are invalid.
sudo apt-get updatetimedatectl statusgrep -R --line-number '^Signed-By:' /etc/apt/sources.list.d
ResolutionRepair trusted repository configuration and time. Never use allow-unauthenticated.
Security notes
- Do not add PPAs or download replacement scripts to work around repository errors.
Alternatives
- Use the supported package from an approved signed Ubuntu mirror.
Stop conditions
- Any signature or candidate-origin warning blocks installation.
config
Enable daily package-list refresh and unattended execution
Create an administrator-owned APT periodic drop-in after the packaged defaults. The values mean once per day, not a precise wall-clock schedule; systemd timer overrides define the controlled execution window later.
Why this step matters
The periodic drop-in explicitly enables daily metadata refresh and unattended execution while separating cadence from the precise systemd wall-clock window.
What to understand
APT periodic values are intervals in days. A value of 1 means due daily and 0 disables the task.
Lexically later administrator files override scalar packaged defaults without editing the vendor file that upgrades may replace.
Weekly autoclean bounds obsolete cache use but does not remove installed packages.
System changes
- Creates `/etc/apt/apt.conf.d/60oneliners-periodic` and changes when APT periodic tasks are considered due.
Syntax explained
Update-Package-Lists "1"- Makes repository metadata refresh due daily.
Unattended-Upgrade "1"- Makes unattended installation due daily.
AutocleanInterval "7"- Runs cache autoclean at seven-day cadence.
/etc/apt/apt.conf.d/60oneliners-periodicAPT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; APT::Periodic::AutocleanInterval "7";
Checkpoint: Confirm periodic values
apt-config dump | grep -E '^APT::Periodic::(Update-Package-Lists|Unattended-Upgrade|AutocleanInterval)'Continue whenThe three scalar values are exactly 1, 1, and 7 with no later contradictory setting.
Stop whenThe merge shows disabled or duplicated contradictory values.
If this step fails
apt-config still reports zero.
Likely causeThe file name/path is wrong, syntax is invalid, or a later file overrides it.
sudo apt-config dumpsudo grep -R --line-number 'Unattended-Upgrade' /etc/apt/apt.conf.d
ResolutionUse one later administrator drop-in with valid semicolons and remove unmanaged conflicting policy through change control.
Security notes
- Keep APT configuration root-owned and immutable to unprivileged deployment users.
Alternatives
- A fleet manager may disable host periodic execution and own scheduling centrally; document that authority explicitly.
Stop conditions
- Do not proceed with ambiguous schedule ownership.
config
Restrict origins and define conservative reboot behavior
Create a later drop-in that permits Ubuntu security and enabled ESM security pockets, blocks automatic reboot while users are logged in, and schedules a required reboot for the declared local-time window. Package blocklists remain empty until evidence justifies a narrow exception.
Why this step matters
Explicit origin patterns and reboot gates define the trust and availability boundary: what may change automatically, when a reboot may occur, and what human activity blocks it.
What to understand
Ubuntu security and enabled ESM security labels are selected. Third-party origins remain excluded until separately approved.
Automatic reboot is scheduled only when the reboot marker exists. `WithUsers=false` prevents reboot while users are logged in but does not coordinate applications.
Removing unused kernels controls `/boot` growth; keep a recovery kernel and test package behavior on the canary.
System changes
- Creates effective unattended origin, reboot, kernel cleanup, and syslog policy.
Syntax explained
Allowed-Origins- Matches the Ubuntu origin and archive names for eligible automatic packages.
Automatic-Reboot=true- Allows unattended-upgrades to schedule reboot when Ubuntu requests one.
Automatic-Reboot-WithUsers=false- Suppresses automatic reboot while users are logged in.
Automatic-Reboot-Time={{rebootTime}}- Passes the declared local time to shutdown.
Remove-Unused-Kernel-Packages=true- Removes no-longer-required kernel packages through unattended cleanup.
SyslogEnable=true- Duplicates high-level unattended messages into syslog/journal for monitoring.
/etc/apt/apt.conf.d/61oneliners-unattendedValues stay on this page and are never sent or saved.
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
"${distro_id}ESMApps:${distro_codename}-apps-security";
"${distro_id}ESM:${distro_codename}-infra-security";
};
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "{{rebootTime}}";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::SyslogEnable "true";Unattended-Upgrade::Allowed-Origins {
"Ubuntu:noble-security";
"UbuntuESMApps:noble-apps-security";
"UbuntuESM:noble-infra-security";
};
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "04:45";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::SyslogEnable "true";Checkpoint: Approve trust and reboot policy
apt-config dump | grep -A20 '^Unattended-Upgrade::Allowed-Origins'Continue whenOnly approved security origins and deliberate reboot controls appear.
Stop whenA broad wildcard, third-party origin, immediate reboot, or users-true setting appears.
If this step fails
An ESM origin is configured but unavailable.
Likely causeUbuntu Pro is not attached or the service is disabled.
pro statusapt-cache policy | grep -A3 -i esm
ResolutionEither enable the entitled official service intentionally or remove the unmatched ESM pattern; do not treat it as a security failure if the estate does not use ESM.
Security notes
- Never use origin `*` or label wildcards to make a dry-run populate.
Alternatives
- Set Automatic-Reboot false and alert a maintenance orchestrator on reboot-required for stateful clusters.
Stop conditions
- No automatic reboot without role-specific drain and recovery design.
config
Place APT timers inside the maintenance window
Override both timers with explicit calendars, a small randomized delay, persistence after missed schedules, and accuracy appropriate to operations. Refresh indexes before the upgrade timer; leave enough time for mirrors, downloads, package configuration, and health checks before {{rebootTime}}.
Why this step matters
Explicit timer calendars transform daily eligibility into an operational window and preserve list-refresh-before-install ordering while randomized delay avoids a synchronized fleet spike.
What to understand
The empty `OnCalendar=` resets packaged values before the replacement is added; omitting the reset would append another schedule.
`Persistent=true` triggers a missed run after boot. Consider whether a host returning during peak business time should patch immediately or be gated by fleet orchestration.
Randomized delay spreads load but means the calendar is the start range, not an exact second.
System changes
- Creates timer drop-ins that replace packaged calendars and change future activation times.
Syntax explained
OnCalendar=- Clears inherited calendar expressions in the timer.
OnCalendar={{listRefreshCalendar}} / {{upgradeCalendar}}- Defines new local wall-clock schedules.
RandomizedDelaySec=15m- Spreads hosts across a fifteen-minute range.
Persistent=true- Catches up a missed activation after downtime.
AccuracySec=1m- Allows one-minute coalescing accuracy.
/etc/systemd/system/apt-daily.timer.d/60-oneliners-window.conf and /etc/systemd/system/apt-daily-upgrade.timer.d/60-oneliners-window.confValues stay on this page and are never sent or saved.
# /etc/systemd/system/apt-daily.timer.d/60-oneliners-window.conf
[Timer]
OnCalendar=
OnCalendar={{listRefreshCalendar}}
RandomizedDelaySec=15m
Persistent=true
AccuracySec=1m
# /etc/systemd/system/apt-daily-upgrade.timer.d/60-oneliners-window.conf
[Timer]
OnCalendar=
OnCalendar={{upgradeCalendar}}
RandomizedDelaySec=15m
Persistent=true
AccuracySec=1m[Timer] OnCalendar= OnCalendar=Mon..Fri *-*-* 03:15 RandomizedDelaySec=15m Persistent=true AccuracySec=1m
Checkpoint: Review calendar ordering
systemd-analyze calendar '{{listRefreshCalendar}}' '{{upgradeCalendar}}'Continue whenBoth parse successfully, refresh precedes upgrade, and enough time remains before {{rebootTime}}.
Stop whenThe schedule crosses an unapproved day/time, overlaps peers, or leaves insufficient maintenance time.
If this step fails
Both old and new schedules appear.
Likely causeThe inherited OnCalendar list was not reset with an empty assignment.
systemctl cat apt-daily.timer apt-daily-upgrade.timersystemctl show apt-daily.timer -p TimersCalendar
ResolutionAdd the empty reset before the replacement in each drop-in, daemon-reload, and inspect next occurrences.
Security notes
- Timer files are privileged policy; prevent unreviewed users from moving updates outside monitoring coverage.
Alternatives
- Use centrally generated staggered calendars per ring.
Stop conditions
- Do not accept a timer by visual inspection without `systemd-analyze calendar`.
verification
Validate APT values and both calendar expressions
Ask APT for the merged policy and systemd for the next occurrences before reloading timers. Verify security origins, reboot gates, and local timezone explicitly; syntax validity alone cannot prove the intended window.
Why this step matters
Merged APT values, parsed calendars, and timezone together define actual behavior; validating only individual files can miss later overrides and local-time errors.
What to understand
`apt-config dump` expands the effective namespace after all apt.conf.d files are read.
`systemd-analyze calendar` shows normalized and next timestamps without activating services.
Timezone must be written into the change record alongside the reboot time because the same `04:45` means different UTC instants.
System changes
- No persistent change; parses merged APT and calendar policy.
Syntax explained
apt-config dump- Displays effective APT configuration after includes and drop-ins.
systemd-analyze calendar- Parses and computes future occurrences for calendar expressions.
timedatectl show -p Timezone- Returns the timezone used to interpret wall-clock policy.
Values stay on this page and are never sent or saved.
apt-config dump | grep -E 'APT::Periodic|Unattended-Upgrade::(Allowed-Origins|Automatic-Reboot|Automatic-Reboot-WithUsers|Automatic-Reboot-Time|Remove-Unused-Kernel-Packages|SyslogEnable)' && systemd-analyze calendar '{{listRefreshCalendar}}' '{{upgradeCalendar}}' && timedatectl show -p Timezone --valueAPT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; Unattended-Upgrade::Automatic-Reboot "true"; Unattended-Upgrade::Automatic-Reboot-WithUsers "false"; Unattended-Upgrade::Automatic-Reboot-Time "04:45"; Original form: Mon..Fri *-*-* 03:15 Next elapse: Wed 2026-07-29 03:15:00 UTC Original form: Mon..Fri *-*-* 03:45 Next elapse: Wed 2026-07-29 03:45:00 UTC Etc/UTC
Checkpoint: Require deterministic policy
Continue whenSecurity origins, reboot values, both next calendar times, ordering, and timezone match the change plan.
Stop whenAny setting is missing, duplicated unexpectedly, or evaluated in the wrong timezone.
If this step fails
A calendar parses but next run is on the wrong day.
Likely causeWeekday/range syntax, timezone, daylight-saving transition, or persistent catch-up semantics were misunderstood.
systemd-analyze calendar --iterations=10 'Mon..Fri *-*-* 03:45'timedatectl status
ResolutionCorrect the expression or use UTC consistently, then inspect at least ten future occurrences including DST boundaries.
Security notes
- Policy output is safe to capture after repository URLs and internal mirror names are redacted.
Alternatives
- Validate rendered configuration in CI and repeat on host to catch environment timezone and overrides.
Stop conditions
- Do not reload timers when the next occurrence is not explicitly approved.
verification
Run an unattended dry-run with debug evidence
Simulate selection and package actions before enabling the new timer schedule. Review allowed origins, proposed package list, kept or blacklisted packages, conffile decisions, and every warning; do not reduce debug output to one success line.
Why this step matters
A debug dry-run is the last no-write checkpoint for origin selection, holds, dependencies, conffiles, and package candidates before automated dpkg activity.
What to understand
Review the complete log, especially allowed origins, packages, kept packages, blacklist, and errors. The final exit code alone is insufficient.
`tee` preserves evidence while PIPESTATUS checks the unattended process rather than tee's success.
A dry-run cannot prove maintainer scripts or runtime service restarts; the canary remains mandatory.
System changes
- Does not install packages; refresh state may already exist and a debug log is written to `/tmp`.
Syntax explained
--dry-run- Simulates eligible upgrades without performing package changes.
--debug- Prints detailed policy, candidate, and decision evidence.
PIPESTATUS[0]- Checks unattended-upgrade's exit status in the pipeline.
sudo unattended-upgrade --dry-run --debug 2>&1 | tee /tmp/oneliners-unattended-dry-run.log; test ${PIPESTATUS[0]} -eq 0Allowed origins are: o=Ubuntu,a=noble-security, o=UbuntuESMApps,a=noble-apps-security, o=UbuntuESM,a=noble-infra-security Checking: openssl ([<Origin component:'main' archive:'noble-security' origin:'Ubuntu' label:'Ubuntu' site:'archive.ubuntu.com'>]) Packages that will be upgraded: libssl3t64 openssl Option --dry-run given, *not* performing real actions $? = 0
Checkpoint: Approve the package plan
Continue whenOnly expected security origins and packages are selected; no removals, prompts, unexplained holds, or errors appear; exit is zero.
Stop whenAny package or origin is unexpected, or a warning cannot be explained.
If this step fails
Dry-run exits nonzero on a conffile prompt.
Likely causeLocal configuration diverges and package policy cannot decide safely.
sudo unattended-upgrade --dry-run --debugsudo debsums -s 2>/dev/nullsudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-old'
ResolutionReview the package's supported conffile transition on the canary, merge intentionally, and rerun; do not force a global keep/replace answer blindly.
Security notes
- The debug log can reveal packages, repositories, and host roles; remove or protect it after the change record is captured.
Alternatives
- Use an isolated clone and Ubuntu snapshot repository for a stronger package rehearsal.
Stop conditions
- No real run after a nonzero or partially reviewed dry-run.
command
Reload, enable, and inspect the controlled timers
Reload the manager, enable both timers, and reset their schedules so the new calendars take effect. Capture next-run timestamps and confirm services are not unexpectedly active before the canary window.
Why this step matters
Reloading and restarting only the timers commits the reviewed schedule while making next-run evidence visible before package services execute.
What to understand
`daemon-reload` loads drop-ins; enable makes timers persistent; restart recalculates their next elapse.
Both backing services should normally be inactive between runs. An active service means package work may already be in progress and must not be interrupted.
Record actual randomized next times and compare them with peer nodes to preserve redundancy.
System changes
- Enables and starts timers with replacement calendars; package services run later when timers elapse.
Syntax explained
daemon-reload- Loads timer drop-ins into the system manager.
enable --now- Persists and activates timer scheduling immediately.
restart ...timer- Recomputes next activation from new policy.
is-active ...service- Checks whether package work is currently running.
sudo systemctl daemon-reload && sudo systemctl enable --now apt-daily.timer apt-daily-upgrade.timer && sudo systemctl restart apt-daily.timer apt-daily-upgrade.timer && systemctl list-timers apt-daily.timer apt-daily-upgrade.timer --all --no-pager && systemctl is-active apt-daily.service apt-daily-upgrade.serviceNEXT LEFT LAST PASSED UNIT ACTIVATES Wed 2026-07-29 03:23:14 UTC 19h n/a n/a apt-daily.timer apt-daily.service Wed 2026-07-29 03:53:01 UTC 19h n/a n/a apt-daily-upgrade.timer apt-daily-upgrade.service inactive inactive
Checkpoint: Approve live timer schedule
Continue whenBoth timers are active, service units are idle, refresh precedes upgrade, and next runs stay inside the canary window.
Stop whenA package service is active unexpectedly or next times violate redundancy.
If this step fails
The timer shows `n/a` for NEXT.
Likely causeCalendar failed to load, timer is inactive, or a condition prevents scheduling.
systemctl status apt-daily.timer apt-daily-upgrade.timer --no-pagerjournalctl -u apt-daily.timer -u apt-daily-upgrade.timer --since '-15 minutes' --no-pager
ResolutionCorrect the timer parse/enable error, daemon-reload, restart timers, and require explicit next occurrences.
Security notes
- Do not manually start the upgrade service merely to make the timer look healthy.
Alternatives
- Keep timers disabled and perform a one-time supervised canary command if the scheduled window cannot be observed yet.
Stop conditions
- No unattended state without active monitoring for the first window.
decision
Observe one canary update and controlled reboot cycle
Keep console and application monitoring open through the first real window. Confirm package success, service health, reboot marker behavior, logged-in-user protection, the scheduled shutdown message, post-boot kernel, and the next timer occurrences before expanding beyond the canary.
Why this step matters
Only a real canary exposes maintainer scripts, service restarts, reboot markers, boot compatibility, and application effects that a dry-run cannot execute.
What to understand
Observe journal, unattended log, dpkg log, service health, application probes, and resource capacity throughout the window.
If reboot is required, confirm the shutdown message names {{rebootTime}} and that active users suppress it. Keep console connected through boot.
After boot, compare kernel, package versions, failed units, application checks, and next timers with the baseline before fleet promotion.
System changes
- Installs eligible security packages; may restart services, remove unused kernels, and schedule a controlled reboot.
Syntax explained
journalctl -u apt-daily-upgrade.service- Shows systemd activation, exit, and service-level errors.
unattended-upgrades.log- Records selection, installation, completion, and reboot decisions.
reboot-required.pkgs- Identifies packages associated with a requested reboot.
systemctl --failed- Surfaces post-update unit regressions.
sudo journalctl -u apt-daily-upgrade.service --since today --no-pager; sudo tail -n 80 /var/log/unattended-upgrades/unattended-upgrades.log; test -f /var/run/reboot-required && cat /var/run/reboot-required.pkgs || echo 'no reboot required'; systemctl --failed --no-pager; systemctl list-timers apt-daily.timer apt-daily-upgrade.timer --all --no-pager2026-07-29 03:47:06,112 INFO Starting unattended upgrades script 2026-07-29 03:47:06,113 INFO Allowed origins are: o=Ubuntu,a=noble-security, o=UbuntuESMApps,a=noble-apps-security, o=UbuntuESM,a=noble-infra-security 2026-07-29 03:47:10,202 INFO Packages that will be upgraded: libssl3t64 openssl 2026-07-29 03:47:22,554 INFO All upgrades installed 2026-07-29 03:47:22,600 WARNING Found /var/run/reboot-required, rebooting 2026-07-29 03:47:22,604 WARNING Shutdown msg: Reboot scheduled for Wed 2026-07-29 04:45:00 UTC 0 loaded units listed.
Checkpoint: Promote or stop after canary
systemctl show apt-daily-upgrade.service -p Result -p ExecMainStatus; systemctl --failed --no-pager; uname -rContinue whenUpdate and any reboot complete inside the window, result is success, no unexplained unit/application failure remains, and timer schedule persists.
Stop whenAny package, service, boot, application, shutdown-time, or monitoring regression is unexplained.
If this step fails
A reboot is scheduled while a user is logged in.
Likely causeEffective `Automatic-Reboot-WithUsers` is true, user detection differs for the session, or another tool scheduled the reboot.
whoapt-config dump | grep Automatic-Rebootshutdown --show 2>/dev/null || truejournalctl --since '-30 minutes' | grep -i shutdown
ResolutionCancel with `shutdown -c`, identify the initiating mechanism, restore the gate, and repeat the canary. Do not assume all remote automation appears in `who`.
Security notes
- Do not disclose the full patch inventory publicly before remediation is complete.
Alternatives
- Set automatic reboot false and have an orchestrator drain, reboot, and validate the canary.
Stop conditions
- One failed canary blocks every later ring.
Finish line
Verification checklist
apt-config dump | grep -E 'APT::Periodic|Unattended-Upgrade::(Allowed-Origins|Automatic-Reboot|Automatic-Reboot-WithUsers|Automatic-Reboot-Time)'Daily periodic work, security-only origins, automatic reboot true, logged-in-user reboot false, and {{rebootTime}} are present exactly once in effective policy.systemctl list-timers apt-daily.timer apt-daily-upgrade.timer --all --no-pagerThe next list refresh and upgrade fall inside the declared local maintenance window, with refresh before installation.systemctl show apt-daily-upgrade.service -p Result -p ExecMainStatus && systemctl --failed --no-pager && sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.logThe service result is success with exit status 0, no unexpected unit is failed, and the log records allowed origins plus either completed upgrades or a clean no-package run.Recovery guidance
Common problems and safe checks
The timer runs, but unattended-upgrade says no packages are allowed while security updates are visible.
Likely causeOrigin patterns do not match actual repository metadata, indexes are stale, phased/pinned/held state differs, or the package comes from an unapproved third-party source.
apt-cache policy opensslapt-get --just-print upgradeapt-config dump | grep -A12 'Unattended-Upgrade::Allowed-Origins'sudo unattended-upgrade --dry-run --debug
ResolutionMatch policy to the official origin metadata shown by APT or correct repository configuration. Do not broaden patterns to every origin as a shortcut.
The host reboots outside the expected clock window.
Likely causeTimezone changed, another reboot mechanism scheduled shutdown, the value was interpreted in local time, or an administrator started a manual reboot.
timedatectl statusapt-config dump | grep Automatic-Reboot-Timejournalctl --since '-1 day' | grep -iE 'reboot|shutdown|unattended'
ResolutionCancel unsafe pending shutdown, restore the approved timezone/window, identify the initiating mechanism, and retest on the canary before automatic reboot is re-enabled.
apt-daily-upgrade fails with a dpkg lock error.
Likely causeInteractive APT, configuration management, image initialization, or another timer overlaps the window.
systemctl status apt-daily-upgrade.service --no-pagerps -ef | grep -E '[a]pt|[d]pkg'journalctl -u apt-daily-upgrade.service --since '-30 minutes' --no-pager
ResolutionLet the legitimate package operation finish, remove overlapping schedules through coordination, run `dpkg --audit`, and retry without deleting lock files.
A service is failed after successful package installation.
Likely causeA package restart exposed configuration incompatibility, a conffile decision retained invalid settings, a dependent service was unavailable, or the application needs migration.
systemctl --failed --no-pagerjournalctl -u example.service --since '-1 hour' --no-pagergrep -A5 -B5 'example' /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
ResolutionRemove the host from traffic, restore service through its tested application rollback or compatible configuration, preserve package evidence, and block fleet promotion—not the package indefinitely—until root cause is fixed.
Reference
Frequently asked questions
Are automatic security updates enabled by default on Ubuntu Server?
Ubuntu Server normally includes and enables unattended security updates, but operators must inspect effective policy, origins, timers, logs, and reboot behavior rather than assuming the default matches their maintenance contract.
Why override both apt timers?
One refreshes package metadata and the other performs unattended upgrade work. Scheduling both establishes ordering and keeps downloads/installation inside the reviewed window.
Should automatic reboot always be enabled?
No. It fits standalone or explicitly coordinated hosts with proven recovery and a safe window. Cluster members and stateful roles often need an orchestrator while host-local automatic reboot remains false.
Does `Automatic-Reboot-WithUsers=false` protect running applications?
No. It checks logged-in users, not business transactions, jobs, quorum, replication, or traffic. Application coordination remains a separate control.
Can I automatically install updates from a PPA?
Technically an explicit origin can be added, but only after the repository's trust, support, signing, compatibility, rollback, and maintenance behavior are approved. This baseline intentionally excludes it.
Recovery
Rollback
Rollback stops future automatic activity, removes only the administrator drop-ins and timer overrides, and restores packaged schedules. It cannot uninstall already applied security updates automatically; package downgrades require separate compatibility, repository, and recovery analysis.
- Cancel a scheduled reboot with `sudo shutdown -c` if it is no longer safe, then record why the maintenance gate failed and keep console access.
- Disable `apt-daily.timer` and `apt-daily-upgrade.timer` while correcting policy; do not stop an active dpkg process or kill unattended-upgrade mid-transaction.
- Remove `/etc/apt/apt.conf.d/60oneliners-periodic`, `/etc/apt/apt.conf.d/61oneliners-unattended`, and both `60-oneliners-window.conf` timer drop-ins, then run `sudo systemctl daemon-reload`.
- Re-enable or restore the organization's prior timers, verify `apt-config dump`, inspect next schedules, and manage pending security updates manually until a corrected policy is approved.
Evidence