Unattended‑Upgrade MailReport Mode Change in Ubuntu 24.04 LTS

Direct answer

Automatic-Reboot does not suppress MailReport. unattended-upgrades decides whether to send mail from the upgrade result (change or error) and decides whether to reboot separately from the post-upgrade reboot-required state. A non-security update that is actually installed is still a change, so MailReport 'on-change' will send the report even when a reboot follows.

unattended-upgrades does not notify logged-in users. During a normal systemd shutdown, systemd-logind emits machine-readable D-Bus signals such as PrepareForShutdown and removes sessions, but it does not create a desktop alert or user-facing notification on behalf of unattended-upgrades. There is no unattended-upgrades setting that makes logind “notify” users.

There is no supported configuration that provides both security-only email and automatic user awareness of reboots. You can get security-only email by restricting origins and using 'on-change', and you can schedule reboots with Automatic-Reboot, but user awareness must come from monitoring the email, the system journal, or external tooling—not from unattended-upgrades itself.

Likely explanation versus confirmed behavior

The independence of mail and reboot follows from the control flow: the report reflects package activity, not shutdown state. What is less certain without testing on your specific image is the no-change case. If /var/run/reboot-required already exists from an earlier manual or non-security install and the current unattended-upgrades run installs nothing, 'on-change' should not mail merely because a reboot occurs. Verify this on a disposable VM rather than assuming your build reboots on a no-change run.

Configuration for security-only email with reboot awareness

MailReport itself does not classify security versus non-security. To receive email only for security updates, restrict the origins unattended-upgrades may act on, then set the report mode.

1. In /etc/apt/apt.conf.d/50unattended-upgrades or a drop-in, limit origins to the 24.04 “noble” security pocket. If you use Ubuntu Pro/ESM, include the ESM security origin as well; otherwise omit it.

Unattended-Upgrade::Allowed-Origins {
    "Ubuntu:noble-security";
};

Alternatively, use Origins-Pattern if your site standardizes on it.

1. Set the mail and reboot controls:

Unattended-Upgrade::Mail "[contact removed]";
Unattended-Upgrade::MailReport "on-change";
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";

Setting Automatic-Reboot-WithUsers to false means an active login session will block the reboot until the window passes or the session ends. Because this default is version-sensitive, confirm the effective value on your target.

Verification before relying on this

• Run apt-config dump | grep -E '^Unattended-Upgrade::(Mail|MailReport|Allowed-Origins|Origins-Pattern|Automatic-Reboot)' to confirm the effective values after drop-ins.
• Run unattended-upgrade --dry-run --debug and check that the printed allowed origins and candidate packages are security-only for noble.
• On a disposable VM, point Mail at a local mailbox, allow one security update, run the real unattended-upgrade, and compare the mailbox and /var/log/unattended-upgrades entry with the shutdown time.
• Confirm mail delivery works (a local mailx/sendmail MTA or relay) before you depend on 'on-change'; a reboot immediately after an upgrade can hide a broken mail path.

One diagnostic detail that changes the recommendation

What is the effective value of Unattended-Upgrade::Automatic-Reboot-WithUsers on your Ubuntu 24.04 target, and do you have interactive desktop sessions that must block reboots? If the default is true on your image, active users will delay reboots and you may want the explicit false setting above; if it is already false, the explicit line is harmless but redundant.