| 2017-04-26 17:24:36 |
Dimitri John Ledkov |
bug |
|
|
added bug |
| 2017-04-26 17:24:44 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Yakkety |
|
| 2017-04-26 17:24:44 |
Dimitri John Ledkov |
bug task added |
|
apt (Ubuntu Yakkety) |
|
| 2017-04-26 17:24:44 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Artful |
|
| 2017-04-26 17:24:44 |
Dimitri John Ledkov |
bug task added |
|
apt (Ubuntu Artful) |
|
| 2017-04-26 17:24:44 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-04-26 17:24:44 |
Dimitri John Ledkov |
bug task added |
|
apt (Ubuntu Xenial) |
|
| 2017-04-26 17:24:44 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-04-26 17:24:44 |
Dimitri John Ledkov |
bug task added |
|
apt (Ubuntu Zesty) |
|
| 2017-04-26 17:24:55 |
Dimitri John Ledkov |
apt (Ubuntu Xenial): status |
New |
Triaged |
|
| 2017-04-26 17:24:57 |
Dimitri John Ledkov |
apt (Ubuntu Yakkety): status |
New |
Triaged |
|
| 2017-04-26 17:24:59 |
Dimitri John Ledkov |
apt (Ubuntu Zesty): status |
New |
Triaged |
|
| 2017-04-26 17:25:00 |
Dimitri John Ledkov |
apt (Ubuntu Artful): status |
New |
Triaged |
|
| 2017-04-26 17:25:02 |
Dimitri John Ledkov |
apt (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2017-04-26 17:25:04 |
Dimitri John Ledkov |
apt (Ubuntu Yakkety): importance |
Undecided |
High |
|
| 2017-04-26 17:25:05 |
Dimitri John Ledkov |
apt (Ubuntu Zesty): importance |
Undecided |
High |
|
| 2017-04-26 17:25:07 |
Dimitri John Ledkov |
apt (Ubuntu Artful): importance |
Undecided |
High |
|
| 2017-04-26 17:26:16 |
Dimitri John Ledkov |
description |
[ Impact ]
* unattended-upgrades are enabled by default in Ubuntu 16.04 and later
* Currently the following three things happen as a monolithic event:
- metadata updates: apt update
- download of updates: apt upgrade --download-only
- application of updates: apt upgrade
* For the long running instances, all of the above happens at random times throughout the day.
* If systems were poweredoff / suspended, this happens on boot / resume
* End-users would like to have predictable timing, and control over when the updates happen.
Considering all of the above, the following new behavior is proposed which should address all concerns in question. It combines all the desired properties from both end-user and mirror perspectives.
[ Proposed Default Behavior ]
* Decouple unattended-upgrades application, from apt update
* apt update:
- shall be a systemd timer based unit, triggered every 12h with a
random delay of 12h, therefore executed randomly twice a day.
- if unattened-upgrades (default on), or download-upgreadaeble-packages
are enabled, it should result in updates being downloaded aka
`apt upgrade --download-only`
* unattended-upgrades:
- shall be a separate systemd timer based unit triggered at 6am local
time with a random delay of 1h, therefore executed between 6am and 7am
local time.
* On boot / resume:
- if we have missed one, or more, apt update timers,
apt update / download upgrades / unattended-upgrade will happen in
sequence. This may result in mirror spikes, but we do want to secure
cold/stale-booted systems as soon as possible.
[Test Case]
* Run system for more than 24h, and check that apt updates were
automatically executed twice.
* Check that unattended upgrades were triggered to be applied at
6am..7am window, if any.
* Poweroff the machine over the period when apt-get update was
scheduled, poweron and observe that apt-get update / download / unattended
upgrade are all performed on boot.
[Regression Potential]
* The newly proposed behavior is a mix of Pre-xenial behavior of "do everything
at 6am..6:30am window" and the xenial+ behavior of "do everything at random
times throughout the day". If there are specific deployments that rely on the
previous types of behaviour they will be able to adjust manually the systemd
timers with the overrides to be executed exactly as they wish; or match the .0
release behaviour that they preffer.
* If timers behavior is coded wrongly the proposed behaviour might not be executed
as intended, thus requiring further SRUs to bring us in-line with the great
expectations.
[Other Info]
* Related bug reports and history:
- bug #1615482
- bug #1554848 |
[ Impact ]
* unattended-upgrades are enabled by default in Ubuntu 16.04 and later
* Currently the following three things happen as a monolithic event:
- metadata updates: apt update
- download of updates: apt upgrade --download-only
- application of updates: apt upgrade
* For the long running instances, all of the above happens at random
times throughout the day.
* If systems were poweredoff / suspended, this happens on boot / resume
* End-users would like to have predictable timing, and control over when
the updates happen.
Considering all of the above, the following new behavior is proposed which should address all concerns in question. It combines all the desired properties from both end-user and mirror perspectives.
[ Proposed Default Behavior ]
* Decouple unattended-upgrades application, from apt update
* apt update:
- shall be a systemd timer based unit, triggered every 12h with a
random delay of 12h, therefore executed randomly twice a day.
- if unattened-upgrades (default on), or download-upgreadaeble-packages
are enabled, it should result in updates being downloaded aka
`apt upgrade --download-only`
* unattended-upgrades:
- shall be a separate systemd timer based unit triggered at 6am local
time with a random delay of 1h, therefore executed between 6am and
7am local time.
* On boot / resume:
- if we have missed one, or more, apt update timers,
apt update / download upgrades / unattended-upgrade will happen in
sequence. This may result in mirror spikes, but we do want to secure
cold/stale-booted systems as soon as possible.
[Test Case]
* Run system for more than 24h, and check that apt updates were
automatically executed twice.
* Check that unattended upgrades were triggered to be applied at
6am..7am window, if any.
* Poweroff the machine over the period when apt-get update was
scheduled, poweron and observe that apt-get update / download / unattended
upgrade are all performed on boot.
[Regression Potential]
* The newly proposed behavior is a mix of Pre-xenial behavior of "do
everything at 6am..6:30am window" and the xenial+ behavior of "do everything at random times throughout the day". If there are specific deployments that rely on the previous types of behaviour they will be able to adjust manually the systemd timers with the overrides to be executed exactly as they wish; or match the .0 release behaviour that they preffer.
* If timers behavior is coded wrongly the proposed behaviour might not be
executed as intended, thus requiring further SRUs to bring us in-line
with the great expectations.
[Other Info]
* Related bug reports and history:
- bug #1615482
- bug #1554848 |
|
| 2017-04-26 17:26:49 |
Dimitri John Ledkov |
description |
[ Impact ]
* unattended-upgrades are enabled by default in Ubuntu 16.04 and later
* Currently the following three things happen as a monolithic event:
- metadata updates: apt update
- download of updates: apt upgrade --download-only
- application of updates: apt upgrade
* For the long running instances, all of the above happens at random
times throughout the day.
* If systems were poweredoff / suspended, this happens on boot / resume
* End-users would like to have predictable timing, and control over when
the updates happen.
Considering all of the above, the following new behavior is proposed which should address all concerns in question. It combines all the desired properties from both end-user and mirror perspectives.
[ Proposed Default Behavior ]
* Decouple unattended-upgrades application, from apt update
* apt update:
- shall be a systemd timer based unit, triggered every 12h with a
random delay of 12h, therefore executed randomly twice a day.
- if unattened-upgrades (default on), or download-upgreadaeble-packages
are enabled, it should result in updates being downloaded aka
`apt upgrade --download-only`
* unattended-upgrades:
- shall be a separate systemd timer based unit triggered at 6am local
time with a random delay of 1h, therefore executed between 6am and
7am local time.
* On boot / resume:
- if we have missed one, or more, apt update timers,
apt update / download upgrades / unattended-upgrade will happen in
sequence. This may result in mirror spikes, but we do want to secure
cold/stale-booted systems as soon as possible.
[Test Case]
* Run system for more than 24h, and check that apt updates were
automatically executed twice.
* Check that unattended upgrades were triggered to be applied at
6am..7am window, if any.
* Poweroff the machine over the period when apt-get update was
scheduled, poweron and observe that apt-get update / download / unattended
upgrade are all performed on boot.
[Regression Potential]
* The newly proposed behavior is a mix of Pre-xenial behavior of "do
everything at 6am..6:30am window" and the xenial+ behavior of "do everything at random times throughout the day". If there are specific deployments that rely on the previous types of behaviour they will be able to adjust manually the systemd timers with the overrides to be executed exactly as they wish; or match the .0 release behaviour that they preffer.
* If timers behavior is coded wrongly the proposed behaviour might not be
executed as intended, thus requiring further SRUs to bring us in-line
with the great expectations.
[Other Info]
* Related bug reports and history:
- bug #1615482
- bug #1554848 |
[ Impact ]
* unattended-upgrades are enabled by default in Ubuntu 16.04 and later
* Currently the following three things happen as a monolithic event:
- metadata updates: apt update
- download of updates: apt upgrade --download-only
- application of updates: apt upgrade
* For the long running instances, all of the above happens at random
times throughout the day.
* If systems were poweredoff / suspended, this happens on boot / resume
* End-users would like to have predictable timing, and control over when
the updates happen.
Considering all of the above, the following new behavior is proposed which should address all concerns in question. It combines all the desired properties from both end-user and mirror perspectives.
[ Proposed Default Behavior ]
* Decouple unattended-upgrades application, from apt update
* apt update:
- shall be a systemd timer based unit, triggered every 12h with a
random delay of 12h, therefore executed randomly twice a day.
- if unattened-upgrades (default on), or download-upgreadaeble-packages
are enabled, it should result in updates being downloaded aka
`apt upgrade --download-only`
* unattended-upgrades:
- shall be a separate systemd timer based unit triggered at 6am local
time with a random delay of 1h, therefore executed between 6am and
7am local time.
* On boot / resume:
- if we have missed one, or more, apt update timers,
apt update / download upgrades / unattended-upgrade will happen in
sequence. This may result in mirror spikes, but we do want to secure
cold/stale-booted systems as soon as possible.
[Test Case]
* Run system for more than 24h, and check that apt updates were
automatically executed twice.
* Check that unattended upgrades were triggered to be applied at
6am..7am window, if any.
* Poweroff the machine over the period when apt-get update was
scheduled, poweron and observe that apt-get update / download /
unattended upgrade are all performed on boot.
[Regression Potential]
* The newly proposed behavior is a mix of Pre-xenial behavior of "do
everything at 6am..6:30am window" and the xenial+ behavior of "do
everything at random times throughout the day". If there are specific
deployments that rely on the previous types of behaviour they will be
able to adjust manually the systemd timers with the overrides to be
executed exactly as they wish; or match the .0 release behaviour that
they preffer.
* If timers behavior is coded wrongly the proposed behaviour might not be
executed as intended, thus requiring further SRUs to bring us in-line
with the great expectations.
[Other Info]
* Related bug reports and history:
- bug #1615482
- bug #1554848 |
|
| 2017-04-26 17:27:04 |
Dimitri John Ledkov |
bug task added |
|
unattended-upgrades (Ubuntu) |
|
| 2017-04-26 17:27:13 |
Dimitri John Ledkov |
unattended-upgrades (Ubuntu Xenial): status |
New |
Triaged |
|
| 2017-04-26 17:27:22 |
Dimitri John Ledkov |
unattended-upgrades (Ubuntu Yakkety): status |
New |
Triaged |
|
| 2017-04-26 17:27:29 |
Dimitri John Ledkov |
unattended-upgrades (Ubuntu Zesty): status |
New |
Triaged |
|
| 2017-04-26 17:27:35 |
Dimitri John Ledkov |
unattended-upgrades (Ubuntu Artful): status |
New |
Triaged |
|
| 2017-04-26 17:27:45 |
Dimitri John Ledkov |
unattended-upgrades (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2017-04-26 17:27:56 |
Dimitri John Ledkov |
unattended-upgrades (Ubuntu Yakkety): importance |
Undecided |
High |
|
| 2017-04-26 17:28:03 |
Dimitri John Ledkov |
unattended-upgrades (Ubuntu Zesty): importance |
Undecided |
High |
|
| 2017-04-26 17:28:10 |
Dimitri John Ledkov |
unattended-upgrades (Ubuntu Artful): importance |
Undecided |
High |
|
| 2017-04-26 18:18:53 |
Julian Andres Klode |
attachment added |
|
diff -w diff https://bugs.launchpad.net/ubuntu/artful/+source/unattended-upgrades/+bug/1686470/+attachment/4868325/+files/apt_lp1686470.diff |
|
| 2017-04-26 18:53:17 |
Julian Andres Klode |
apt (Ubuntu Artful): status |
Triaged |
Fix Committed |
|
| 2017-04-26 20:09:54 |
Steve Langasek |
bug |
|
|
added subscriber Steve Langasek |
| 2017-04-26 20:25:58 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
| 2017-04-26 22:36:34 |
Paul Gear |
bug |
|
|
added subscriber The Canonical Sysadmins |
| 2017-04-26 22:41:36 |
Haw Loeung |
bug |
|
|
added subscriber Haw Loeung |
| 2017-04-26 22:47:42 |
Steve Langasek |
summary |
Apt updates that are uniformally spread across all timezones, with predictable application windows |
Apt updates that are uniformly spread across all timezones, with predictable application windows |
|
| 2017-04-26 22:53:44 |
paz |
bug |
|
|
added subscriber paz |
| 2017-04-27 10:19:27 |
Launchpad Janitor |
apt (Ubuntu Artful): status |
Fix Committed |
Fix Released |
|
| 2017-04-27 23:18:14 |
Julian Andres Klode |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861357 |
|
| 2017-04-27 23:18:14 |
Julian Andres Klode |
bug task added |
|
apt (Debian) |
|
| 2017-04-28 00:29:34 |
Bug Watch Updater |
apt (Debian): status |
Unknown |
New |
|
| 2017-05-17 22:19:37 |
Tony Garcia |
bug |
|
|
added subscriber Tony Garcia |
| 2017-05-19 22:20:56 |
Oliver Brakmann |
bug |
|
|
added subscriber Oliver Brakmann |
| 2017-06-01 09:16:19 |
Julian Andres Klode |
attachment added |
|
unattended-upgrade.diff https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1686470/+attachment/4887192/+files/unattended-upgrade.diff |
|
| 2017-06-01 20:57:52 |
Julian Andres Klode |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863911 |
|
| 2017-06-01 20:57:52 |
Julian Andres Klode |
bug task added |
|
unattended-upgrades (Debian) |
|
| 2017-06-01 22:09:11 |
Bug Watch Updater |
unattended-upgrades (Debian): status |
Unknown |
New |
|
| 2017-06-02 00:15:04 |
Jarno Suni |
bug |
|
|
added subscriber Jarno Suni |
| 2017-06-02 02:58:29 |
Bug Watch Updater |
apt (Debian): status |
New |
Fix Released |
|
| 2017-06-19 12:21:28 |
Julian Andres Klode |
apt (Ubuntu Xenial): status |
Triaged |
In Progress |
|
| 2017-06-19 12:21:37 |
Julian Andres Klode |
apt (Ubuntu Yakkety): status |
Triaged |
In Progress |
|
| 2017-06-19 12:22:11 |
Julian Andres Klode |
apt (Ubuntu Zesty): status |
Triaged |
In Progress |
|
| 2017-06-22 15:36:38 |
Dimitri John Ledkov |
unattended-upgrades (Ubuntu Artful): assignee |
|
Dimitri John Ledkov (xnox) |
|
| 2017-06-22 15:36:45 |
Dimitri John Ledkov |
unattended-upgrades (Ubuntu Zesty): assignee |
|
Dimitri John Ledkov (xnox) |
|
| 2017-06-22 15:36:54 |
Dimitri John Ledkov |
unattended-upgrades (Ubuntu Yakkety): assignee |
|
Dimitri John Ledkov (xnox) |
|
| 2017-06-22 15:37:06 |
Dimitri John Ledkov |
unattended-upgrades (Ubuntu Xenial): assignee |
|
Dimitri John Ledkov (xnox) |
|
| 2017-06-22 15:40:00 |
Dimitri John Ledkov |
apt (Ubuntu Artful): assignee |
|
Dimitri John Ledkov (xnox) |
|
| 2017-06-22 15:40:09 |
Dimitri John Ledkov |
apt (Ubuntu Zesty): assignee |
|
Dimitri John Ledkov (xnox) |
|
| 2017-06-22 15:40:16 |
Dimitri John Ledkov |
apt (Ubuntu Yakkety): assignee |
|
Dimitri John Ledkov (xnox) |
|
| 2017-06-22 15:40:24 |
Dimitri John Ledkov |
apt (Ubuntu Xenial): assignee |
|
Dimitri John Ledkov (xnox) |
|
| 2017-07-24 06:48:37 |
Robin Baumgartner |
bug |
|
|
added subscriber Robin Baumgartner |
| 2017-07-25 10:18:07 |
Bug Watch Updater |
unattended-upgrades (Debian): status |
New |
Fix Committed |
|
| 2017-07-27 20:32:04 |
Adam Conrad |
apt (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2017-07-27 20:32:10 |
Adam Conrad |
apt (Ubuntu Yakkety): status |
In Progress |
Won't Fix |
|
| 2017-07-27 20:32:13 |
Adam Conrad |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-07-27 20:32:17 |
Adam Conrad |
bug |
|
|
added subscriber SRU Verification |
| 2017-07-27 20:32:23 |
Adam Conrad |
tags |
patch |
patch verification-needed verification-needed-xenial |
|
| 2017-07-27 20:32:24 |
Adam Conrad |
unattended-upgrades (Ubuntu Yakkety): status |
Triaged |
Won't Fix |
|
| 2017-07-27 20:37:08 |
Adam Conrad |
apt (Ubuntu Zesty): status |
In Progress |
Fix Committed |
|
| 2017-07-31 14:57:35 |
Dimitri John Ledkov |
tags |
patch verification-needed verification-needed-xenial |
patch verification-done-xenial verification-needed |
|
| 2017-07-31 14:57:42 |
Dimitri John Ledkov |
tags |
patch verification-done-xenial verification-needed |
patch verification-done verification-done-xenial |
|
| 2017-07-31 16:25:38 |
Launchpad Janitor |
apt (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2017-07-31 16:25:49 |
Adam Conrad |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2017-07-31 19:37:50 |
Steve Langasek |
description |
[ Impact ]
* unattended-upgrades are enabled by default in Ubuntu 16.04 and later
* Currently the following three things happen as a monolithic event:
- metadata updates: apt update
- download of updates: apt upgrade --download-only
- application of updates: apt upgrade
* For the long running instances, all of the above happens at random
times throughout the day.
* If systems were poweredoff / suspended, this happens on boot / resume
* End-users would like to have predictable timing, and control over when
the updates happen.
Considering all of the above, the following new behavior is proposed which should address all concerns in question. It combines all the desired properties from both end-user and mirror perspectives.
[ Proposed Default Behavior ]
* Decouple unattended-upgrades application, from apt update
* apt update:
- shall be a systemd timer based unit, triggered every 12h with a
random delay of 12h, therefore executed randomly twice a day.
- if unattened-upgrades (default on), or download-upgreadaeble-packages
are enabled, it should result in updates being downloaded aka
`apt upgrade --download-only`
* unattended-upgrades:
- shall be a separate systemd timer based unit triggered at 6am local
time with a random delay of 1h, therefore executed between 6am and
7am local time.
* On boot / resume:
- if we have missed one, or more, apt update timers,
apt update / download upgrades / unattended-upgrade will happen in
sequence. This may result in mirror spikes, but we do want to secure
cold/stale-booted systems as soon as possible.
[Test Case]
* Run system for more than 24h, and check that apt updates were
automatically executed twice.
* Check that unattended upgrades were triggered to be applied at
6am..7am window, if any.
* Poweroff the machine over the period when apt-get update was
scheduled, poweron and observe that apt-get update / download /
unattended upgrade are all performed on boot.
[Regression Potential]
* The newly proposed behavior is a mix of Pre-xenial behavior of "do
everything at 6am..6:30am window" and the xenial+ behavior of "do
everything at random times throughout the day". If there are specific
deployments that rely on the previous types of behaviour they will be
able to adjust manually the systemd timers with the overrides to be
executed exactly as they wish; or match the .0 release behaviour that
they preffer.
* If timers behavior is coded wrongly the proposed behaviour might not be
executed as intended, thus requiring further SRUs to bring us in-line
with the great expectations.
[Other Info]
* Related bug reports and history:
- bug #1615482
- bug #1554848 |
[ Impact ]
* unattended-upgrades are enabled by default in Ubuntu 16.04 and later
* Currently the following three things happen as a monolithic event:
- metadata updates: apt update
- download of updates: apt upgrade --download-only
- application of updates: apt upgrade
* For the long running instances, all of the above happens at random
times throughout the day.
* If systems were poweredoff / suspended, this happens on boot / resume
* End-users would like to have predictable timing, and control over when
the updates happen.
Considering all of the above, the following new behavior is proposed which should address all concerns in question. It combines all the desired properties from both end-user and mirror perspectives.
[ Proposed Default Behavior ]
* Decouple unattended-upgrades application, from apt update
* apt update:
- shall be a systemd timer based unit, triggered every 12h with a
random delay of 12h, therefore executed randomly twice a day.
- if unattened-upgrades (default on), or download-upgreadaeble-packages
are enabled, it should result in updates being downloaded aka
`apt upgrade --download-only`
* unattended-upgrades:
- shall be a separate systemd timer based unit triggered at 6am local
time with a random delay of 1h, therefore executed between 6am and
7am local time.
* On boot / resume:
- if we have missed one, or more, apt update timers,
apt update / download upgrades / unattended-upgrade will happen in
sequence. This may result in mirror spikes, but we do want to secure
cold/stale-booted systems as soon as possible.
[Test Case]
* Run system for more than 24h, and check that apt updates were
automatically executed twice.
* Check that unattended upgrades were triggered to be applied at
6am..7am window, if any.
* Poweroff the machine over the period when apt-get update was
scheduled, poweron and observe that apt-get update / download /
unattended upgrade are all performed on boot.
* Downgrade systemd to the release version of the package (from
-security). Then run 'sudo systemctl start apt-daily.service'.
Confirm that the systemd package is re-upgraded.
[Regression Potential]
* The newly proposed behavior is a mix of Pre-xenial behavior of "do
everything at 6am..6:30am window" and the xenial+ behavior of "do
everything at random times throughout the day". If there are specific
deployments that rely on the previous types of behaviour they will be
able to adjust manually the systemd timers with the overrides to be
executed exactly as they wish; or match the .0 release behaviour that
they prefer.
* If timers behavior is coded wrongly the proposed behaviour might not be
executed as intended, thus requiring further SRUs to bring us in-line
with the great expectations.
[Other Info]
* Related bug reports and history:
- bug #1615482
- bug #1554848 |
|
| 2017-07-31 19:40:45 |
Steve Langasek |
unattended-upgrades (Ubuntu Xenial): status |
Triaged |
In Progress |
|
| 2017-07-31 19:40:45 |
Steve Langasek |
unattended-upgrades (Ubuntu Xenial): assignee |
Dimitri John Ledkov (xnox) |
Steve Langasek (vorlon) |
|
| 2017-07-31 19:40:57 |
Steve Langasek |
unattended-upgrades (Ubuntu Zesty): status |
Triaged |
In Progress |
|
| 2017-07-31 19:40:57 |
Steve Langasek |
unattended-upgrades (Ubuntu Zesty): assignee |
Dimitri John Ledkov (xnox) |
Steve Langasek (vorlon) |
|
| 2017-07-31 22:17:42 |
Dimitri John Ledkov |
description |
[ Impact ]
* unattended-upgrades are enabled by default in Ubuntu 16.04 and later
* Currently the following three things happen as a monolithic event:
- metadata updates: apt update
- download of updates: apt upgrade --download-only
- application of updates: apt upgrade
* For the long running instances, all of the above happens at random
times throughout the day.
* If systems were poweredoff / suspended, this happens on boot / resume
* End-users would like to have predictable timing, and control over when
the updates happen.
Considering all of the above, the following new behavior is proposed which should address all concerns in question. It combines all the desired properties from both end-user and mirror perspectives.
[ Proposed Default Behavior ]
* Decouple unattended-upgrades application, from apt update
* apt update:
- shall be a systemd timer based unit, triggered every 12h with a
random delay of 12h, therefore executed randomly twice a day.
- if unattened-upgrades (default on), or download-upgreadaeble-packages
are enabled, it should result in updates being downloaded aka
`apt upgrade --download-only`
* unattended-upgrades:
- shall be a separate systemd timer based unit triggered at 6am local
time with a random delay of 1h, therefore executed between 6am and
7am local time.
* On boot / resume:
- if we have missed one, or more, apt update timers,
apt update / download upgrades / unattended-upgrade will happen in
sequence. This may result in mirror spikes, but we do want to secure
cold/stale-booted systems as soon as possible.
[Test Case]
* Run system for more than 24h, and check that apt updates were
automatically executed twice.
* Check that unattended upgrades were triggered to be applied at
6am..7am window, if any.
* Poweroff the machine over the period when apt-get update was
scheduled, poweron and observe that apt-get update / download /
unattended upgrade are all performed on boot.
* Downgrade systemd to the release version of the package (from
-security). Then run 'sudo systemctl start apt-daily.service'.
Confirm that the systemd package is re-upgraded.
[Regression Potential]
* The newly proposed behavior is a mix of Pre-xenial behavior of "do
everything at 6am..6:30am window" and the xenial+ behavior of "do
everything at random times throughout the day". If there are specific
deployments that rely on the previous types of behaviour they will be
able to adjust manually the systemd timers with the overrides to be
executed exactly as they wish; or match the .0 release behaviour that
they prefer.
* If timers behavior is coded wrongly the proposed behaviour might not be
executed as intended, thus requiring further SRUs to bring us in-line
with the great expectations.
[Other Info]
* Related bug reports and history:
- bug #1615482
- bug #1554848 |
[ Impact ]
* unattended-upgrades are enabled by default in Ubuntu 16.04 and later
* Currently the following three things happen as a monolithic event:
- metadata updates: apt update
- download of updates: apt upgrade --download-only
- application of updates: apt upgrade
* For the long running instances, all of the above happens at random
times throughout the day.
* If systems were poweredoff / suspended, this happens on boot / resume
* End-users would like to have predictable timing, and control over when
the updates happen.
Considering all of the above, the following new behavior is proposed which should address all concerns in question. It combines all the desired properties from both end-user and mirror perspectives.
[ Proposed Default Behavior ]
* Decouple unattended-upgrades application, from apt update
* apt update:
- shall be a systemd timer based unit, triggered every 12h with a
random delay of 12h, therefore executed randomly twice a day.
- if unattened-upgrades (default on), or download-upgreadaeble-packages
are enabled, it should result in updates being downloaded aka
`apt upgrade --download-only`
* unattended-upgrades:
- shall be a separate systemd timer based unit triggered at 6am local
time with a random delay of 1h, therefore executed between 6am and
7am local time.
* On boot / resume:
- if we have missed one, or more, apt update timers,
apt update / download upgrades / unattended-upgrade will happen in
sequence. This may result in mirror spikes, but we do want to secure
cold/stale-booted systems as soon as possible.
[Test Case]
* Run system for more than 24h, and check that apt updates were
automatically executed twice.
* Check that unattended upgrades were triggered to be applied at
6am..7am window, if any.
* Poweroff the machine over the period when apt-get update was
scheduled, poweron and observe that apt-get update / download /
unattended upgrade are all performed on boot.
* Downgrade systemd to the release version of the package (from
-security). Remove apt periodic stamp files rm /var/lib/apt/periodic/*.
Then run 'sudo systemctl start apt-daily.service'.
Confirm that the systemd package is downloaded, but not upgraded.
[Regression Potential]
* The newly proposed behavior is a mix of Pre-xenial behavior of "do
everything at 6am..6:30am window" and the xenial+ behavior of "do
everything at random times throughout the day". If there are specific
deployments that rely on the previous types of behaviour they will be
able to adjust manually the systemd timers with the overrides to be
executed exactly as they wish; or match the .0 release behaviour that
they prefer.
* If timers behavior is coded wrongly the proposed behaviour might not be
executed as intended, thus requiring further SRUs to bring us in-line
with the great expectations.
[Other Info]
* Related bug reports and history:
- bug #1615482
- bug #1554848 |
|
| 2017-08-01 02:33:10 |
Adam Conrad |
unattended-upgrades (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2017-08-01 02:33:13 |
Adam Conrad |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-08-01 02:33:20 |
Adam Conrad |
tags |
patch verification-done verification-done-xenial |
patch verification-needed verification-needed-xenial |
|
| 2017-08-01 02:33:53 |
Adam Conrad |
unattended-upgrades (Ubuntu Artful): status |
Triaged |
Fix Committed |
|
| 2017-08-01 02:34:18 |
Adam Conrad |
unattended-upgrades (Ubuntu Zesty): status |
In Progress |
Fix Committed |
|
| 2017-08-01 02:34:27 |
Adam Conrad |
tags |
patch verification-needed verification-needed-xenial |
patch verification-needed verification-needed-xenial verification-needed-zesty |
|
| 2017-08-01 04:50:56 |
Launchpad Janitor |
unattended-upgrades (Ubuntu Artful): status |
Fix Committed |
Fix Released |
|
| 2017-08-01 09:59:32 |
Launchpad Janitor |
unattended-upgrades (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2017-08-01 10:01:34 |
Dimitri John Ledkov |
tags |
patch verification-needed verification-needed-xenial verification-needed-zesty |
patch verification-done verification-done-xenial verification-needed-zesty |
|
| 2017-08-09 02:54:08 |
Bug Watch Updater |
unattended-upgrades (Debian): status |
Fix Committed |
Fix Released |
|
| 2017-08-11 19:47:55 |
Steve Langasek |
tags |
patch verification-done verification-done-xenial verification-needed-zesty |
patch verification-done-xenial verification-needed-zesty |
|
| 2017-09-06 09:59:18 |
Dimitri John Ledkov |
tags |
patch verification-done-xenial verification-needed-zesty |
patch verification-done-xenial verification-done-zesty |
|
| 2017-09-13 16:00:18 |
Launchpad Janitor |
apt (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
| 2017-09-13 16:00:36 |
Launchpad Janitor |
unattended-upgrades (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
| 2017-09-29 17:25:18 |
Francis Ginther |
tags |
patch verification-done-xenial verification-done-zesty |
id-597a831a26eaec02914e6202 patch verification-done-xenial verification-done-zesty |
|
| 2018-06-12 14:51:37 |
Mikkel Kirkgaard Nielsen |
bug |
|
|
added subscriber Mikkel Kirkgaard Nielsen |
| 2018-12-03 19:16:15 |
Brian Murray |
unattended-upgrades (Ubuntu Xenial): status |
Fix Released |
Fix Committed |
|
| 2018-12-03 19:16:31 |
Brian Murray |
tags |
id-597a831a26eaec02914e6202 patch verification-done-xenial verification-done-zesty |
id-597a831a26eaec02914e6202 patch verification-done-zesty verification-needed verification-needed-xenial |
|
| 2019-01-22 13:10:15 |
Launchpad Janitor |
unattended-upgrades (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2019-02-09 19:32:09 |
Mathew Hodson |
tags |
id-597a831a26eaec02914e6202 patch verification-done-zesty verification-needed verification-needed-xenial |
id-597a831a26eaec02914e6202 patch verification-done-xenial verification-done-zesty |
|
