It seems reasonable that setting TZ=UTC0 for date --iso-8601 could help
(as that's where a time zone is relevant, the +%s conversion it is not
relevant for).
But then this causes unwanted behaviour for people far off UTC, I guess,
so it's not a solution - It's entirely unclear to me whether a solution
exists given that we allow arbitrary intervals in settings.
Always-on machines (or well, always connected machines) should be
configured with the interval set to 0 (disabling timestamp checks), and
the timer should be configured to run at the appropriate times.
To resolve issues with skipped runs elsewhere, we really need to resolve
the issue that systemd can't reschedule failed timer services, and then
remove the options inside apt.conf, as having dynamic timers in systemd
and then a fixed check inside the script does not really work (hence why
we annoyingly run it twice a day to give it a chance to fixup time
skew).
** Changed in: apt (Ubuntu)
Status: Confirmed => Won't Fix
** Changed in: apt (Ubuntu)
Status: Won't Fix => Triaged
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1824088
Title:
unattended upgrade ran one day after schedule
Status in apt package in Ubuntu:
Triaged
Bug description:
I have noticed a strange behaviour in unattended upgrades. The host in
question is scheduled to run upgrades on Mondays every second week.
However, this week it ran upgrades on Tuesday instead (2019-04-09).
This is the first time I’ve noticed this behaviour. I checked the logs
in /var/log/apt/history.log* and I saw that worked as intended up
until this week. Upgrades ran as expected on 2019-03-11 and
2019-03-25, which where both Mondays.
The schedule was set with the line 'APT::Periodic::Unattended-Upgrade
"14";' in the file /etc/apt/apt.conf.d/20auto-upgrades.
Could it be daylight savings time that has caused skewing of the
schedule?
The server is located in Sweden and on 2019-03-31 we switched from CET
to CEST. If the time diff is calculated with hours instead of calendar
days passed, perhaps the missing hour on 2019-03-31 caused the
scheduler to believe that on Monday 2019-03-08, two weeks (336 hours)
had not yet passed.
ADDITIONAL INFO
Description: Ubuntu 16.04.6 LTS
Release: 16.04
apt:
Installed: 1.2.29ubuntu0.1
Candidate: 1.2.31
Version table:
1.2.31 500
500 http://se.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
*** 1.2.29ubuntu0.1 500
500 http://security.ubuntu.com/ubuntu xenial-security/main amd64
Packages
100 /var/lib/dpkg/status
1.2.10ubuntu1 500
500 http://se.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
unattended-upgrades:
Installed: 0.90ubuntu0.10
Candidate: 0.90ubuntu0.10
Version table:
*** 0.90ubuntu0.10 500
500 http://se.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
500 http://se.archive.ubuntu.com/ubuntu xenial-updates/main i386
Packages
500 http://security.ubuntu.com/ubuntu xenial-security/main amd64
Packages
500 http://security.ubuntu.com/ubuntu xenial-security/main i386
Packages
100 /var/lib/dpkg/status
0.90 500
500 http://se.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
500 http://se.archive.ubuntu.com/ubuntu xenial/main i386 Packages
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: apt 1.2.29ubuntu0.1
ProcVersionSignature: Ubuntu 4.4.0-142.168-generic 4.4.167
Uname: Linux 4.4.0-142-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.18
Architecture: amd64
Date: Wed Apr 10 09:06:49 2019
InstallationDate: Installed on 2017-12-28 (467 days ago)
InstallationMedia: Ubuntu-Server 16.04.3 LTS "Xenial Xerus" - Release amd64
(20170801)
SourcePackage: apt
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1824088/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
