Ubuntu Wiki

This page contains the notes from Scott and Colin's session braindumping the expected behaviour of the hardware and system wall clocks.

Players

Hardware Clock:

• A physical clock able to maintain the time while the system is otherwise powered off, either by relying on chemical or mechanical working or though its own discrete power source.

System Wall Clock:

• A software clock maintained by the kernel while the system is powered on.

Network Clock:

• A non-specific accurate clock available over the network.

The hardware clock and network clock are reliable, we can rely on them to maintain an incrementing time while the system is powered off. The system wall clock is unreliable because it cannot.

The system wall clock and network clock are accurate, we can rely on them to maintain the correct time. The hardware clock is inaccurate because it may lose time.

We use the system wall clock for time operations, since it is both reliable and accurate. So that we can track time while powered off, we synchronise this to and from the hardware clock which is reliable. But because the hardware clock is inaccurate, we regularly resynchronise both the system clock and hardware clock with a network clock.

Timezones

Ideally all clocks would operate free of timezones, storing only UTC. We would then apply the timezone adjustment, accounting for daylight savings and local differences, in software (ie. in the C library) based on the desired timezone.

Indeed, this is the case for the network clock and the system clock; and since software retrieves the time from the system clock, it applies the adjustments.

Unfortunately we can't always keep the hardware clock in UTC. While this is our preferred setting, and our default for pristine Ubuntu installations, other operating systems such as Windows store local time in the hardware clock instead. Thus when installing Ubuntu alongside Windows, we have to co-operate and also store local time into the hardware clock.

This means that there may be a delta between the hardware clock and system clock.

• on boot, the system clock is set from the hardware clock. It must be adjusted by this delta.
• whenever the time is changed, this delta must be taken into account and both the hardware clock and system clock set with it in mind.
• whenever the timezone is changed, this delta must be taken into account, and only the hardware clock set with it in mind (the system clock is unaffected by timezone changes).

A tangential discussion began about being evil and changing Windows (by registry edit) to store the clock in UTC. And then we realised we had a bug:

• the installer should not set Ubuntu up to store localtime in the hardware clock if this registry setting has been changed by the user.

Filesystem considerations

The filesystem metadata is one of the most important consumers of system clock information, since it is highly sensitive to time moving backwards. Filesystem events appear to have happened in the future, and this is a consistency that needs to be corrected by fsck.

If the system clock is changed after filesystem metadata has been written (ie. after the filesystem is checked or mounted writable), and that change is backwards, then the filesystem will be inconsistent.

What happens is:

1. the hardware clock is in localtime, WEST of UTC
2. the system clock is in UTC
3. the filesystem is unmounted, the UTC timestamp is written
4. the system is rebooted
5. the system boots, the system clock is set from the hardware clock, and is thus LESS than it should be
6. the filesystem modification time is in the future
7. fsck corrects this inconsistency
8. the system boot continues
9. the system clock is adjusted to UTC

10. repeat from step 3

The only way to break this cycle is for the downtime between reboots to be greater than the offset between UTC and localtime. And notably, this bug is not observed by users who are EAST of UTC, or in GMT.