Bug #9364
Do not set the hardware clock to the system time on shutdown
100%
Description
As discovered when looking into a similar problem on Jessie (Bug #9363), util-linux’s hwclock.sh on Wheezy is supposed to set the hardware clock to the system time on shutdown, which contradicts one of our design goals.
And indeed, on Tails 1.3.2 this seems to be confirmed by:
root@amnesia:~# hwclock -r
Sat May 9 13:05:37 2015 -0.469382 seconds
root@amnesia:~# hwclock --set --date="2010-01-01 12:00:00"
root@amnesia:~# hwclock -r
Fri Jan 1 12:00:04 2010 -0.767842 seconds
root@amnesia:~# date
Sat May 9 13:06:29 UTC 2015
root@amnesia:~# /etc/init.d/hwclock.sh stop
[info] Saving the system clock.
[info] Hardware Clock updated to Sat May 9 13:06:36 UTC 2015.
root@amnesia:~# hwclock -r
Sat May 9 13:06:40 2015 -0.500988 secondsI didn’t check on bare metal whether the time set in the hardware clock survives a reboot yet. I’m pretty sure I did verify that it didn’t in the past, but it was surely during Squeeze (or even Lenny) area, so perhaps it was caused by a bug that was fixed in Wheezy.
Sadly, if we tried to fix this by setting HWCLOCKACCESS=no in /etc/default/hwclock, then this would also disable sync’ing system time from the hardware clock on startup, which is not desirable. So, we’ll have to patch the initscript’s LSB headers so that it’s not run at shutdown/reboot time. Not worth improving this in Debian, since that initscript is obsolete in Jessie anyway.
Subtasks
History
#1 Updated by intrigeri 2015-05-09 14:52:51
- Status changed from New to Confirmed
#2 Updated by BitingBird 2015-05-09 15:39:49
- related to
Bug #9363: Disable hwclock-save.service on Jessie added
#3 Updated by BitingBird 2015-05-09 15:40:04
- Description updated
#4 Updated by intrigeri 2015-05-16 10:53:55
- Status changed from Confirmed to In Progress
Applied in changeset commit:3f0ac5073441160a0745a23225465ba9b5438977.
#5 Updated by intrigeri 2015-05-16 10:56:40
- % Done changed from 0 to 10
- Feature Branch set to bugfix/9364-do-not-modify-hardware-clock
#6 Updated by intrigeri 2015-05-17 10:48:47
Next step: build an ISO, run the relevant parts of the automated test suite on it, and test it on bare metal to make sure it indeed improves things, or at least doesn’t break anything.
#7 Updated by intrigeri 2015-05-31 18:21:57
- % Done changed from 10 to 20
Passes features/time_syncing.feature.
#8 Updated by intrigeri 2015-06-05 17:22:27
- Assignee changed from intrigeri to anonym
- % Done changed from 20 to 30
- QA Check set to Ready for QA
#9 Updated by anonym 2015-06-10 23:24:06
- related to
Bug #9557: Write regression test for the hardware clock not being saved added
#10 Updated by anonym 2015-06-11 00:35:23
- Assignee changed from anonym to intrigeri
- QA Check changed from Ready for QA to Info Needed
Did you manage to confirm that without this fix, then the hardware clock is actually set on shutdown? I booted Tails 1.4 in KVM/Qemu, set $CRAZY_TIME_1, hwclock -w, set $CRAZY_TIME_2, reboot. When Tails booted again then hwclock -r (and date of course) still reports $CRAZY_TIME_1, so $CRAZY_TIME_2 was never set at shutdown by hwclock.sh.
#11 Updated by intrigeri 2015-06-11 07:35:56
- Assignee changed from intrigeri to anonym
- QA Check changed from Info Needed to Ready for QA
> Did you manage to confirm that without this fix, then the hardware clock is actually set on shutdown?
Nope, as said in my merge request on -dev@ I couldn’t easily find an adequate bare metal machine to do that, and I (perhaps wrongly) prioritized submitting this merge request earlier. Note that I didn’t want to trust QEMU’s hardware clock implementation to test this.
#12 Updated by anonym 2015-06-11 11:41:28
- Assignee changed from anonym to intrigeri
- QA Check changed from Ready for QA to Info Needed
intrigeri wrote:
> Note that I didn’t want to trust QEMU’s hardware clock implementation to test this.
Ok. My test quite clearly indicates that the hardware clock implementation does seem to do what we’d expect of it, i.e. it’s kept across a “warm” reboot, at least.
Any way, my tests in Tails 1.4 indicates that even without your fix, we do not save the hardware clock. Indeed, it isn’t present anywhere in /etc/rc*.d, and from my reading of live-build’s lb_chroot_sysvinit it seems like this should be expected. To be extra sure, I added a sleep 30 (in the top-level) so I definitely would notice if the script was run on shutdown/reboot, but I never noticed such a sleep. As for why the script is started during boot at all, I have no idea. Do you? (I noticed that it’s listed as a “TARGET” in /etc/init.d/.depend.boot, whatever that means)
Still I’d like to merge your branch for completeness (and I do not expect a high maintenance burden for the patch, which we’ll drop in Jessie any way). What do you think?
(Btw, I remember us looking into this at least twice before years ago (probably on Debian Lenny and Squeeze) and we concluded the same: the hardware clock is never written too. We did get a few reports from users that it did, though, but we could never confirm it (and it might as well be a confusion about UTC vs local timezone).)
#13 Updated by intrigeri 2015-06-11 11:49:25
- Assignee changed from intrigeri to anonym
- QA Check changed from Info Needed to Ready for QA
> Any way, my tests in Tails 1.4 indicates that even without your fix, we do not save the hardware clock.
Cool.
> As for why the script is started during boot at all, I have no idea. Do you?
No.
> Still I’d like to merge your branch for completeness (and I do not expect a high maintenance burden for the patch, which we’ll drop in Jessie any way). What do you think?
+1
#14 Updated by anonym 2015-06-11 12:21:18
- Status changed from In Progress to Fix committed
- % Done changed from 30 to 100
Applied in changeset commit:3b5fd763a6d96a7f88ac410aa911cd1fcb151877.
#15 Updated by anonym 2015-06-11 12:22:00
- Assignee deleted (
anonym) - QA Check changed from Ready for QA to Pass
#16 Updated by intrigeri 2015-07-03 03:39:42
- Status changed from Fix committed to Resolved