settimeofday() not called when UTC=yes

Bug #426886 reported by Kevin Knerr
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
util-linux (Ubuntu)
Fix Released
Medium
Scott James Remnant (Canonical)

Bug Description

Binary package hint: sysvinit

1) Ubuntu 9.04
2) sysvinit 2.86.ds1-61ubuntu11
3) Mount a vfat medium, like a camera. The file timestamps should reflect the time the photo was taken.
4) The file timestamp is offset by the difference between local time and UTC.

In https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/278429 , Scott James Remnant wrote "UTC=yes is the correct and sane default: the only reason you would ever store any other time in your system clock is when dual-booting."

Normally, I would agree with this. However, I have discovered that using UTC as the default for the system clock causes incorrect offsets when mounting vfat media. The kernel uses sys_tz to preadjust timestamps on vfat and other filesystems which use local time instead of UTC. (cf http://lkml.org/lkml/2008/6/27/16 ). This negates the effect of the normal user space translation of UTC timestamps to the user's local time.

I respectfully suggest that this need to compensate for vfat's use of local time forces the kernel to assume that system time is also local time. This in turn means that "UTC=yes" is not the correct default for systems which will be mounting vfat media.

Related branches

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

While your interpretation of the problem is incorrect, you have noticed a valid bug. When UTC=yes, we never set set sys_tz because this is set as a side-effect of stepping the system clock when the hardware clock was in localtime.

Changed in sysvinit (Ubuntu):
status: New → Invalid
affects: sysvinit (Ubuntu) → util-linux (Ubuntu)
Changed in util-linux (Ubuntu):
importance: Undecided → Medium
status: Invalid → Triaged
summary: - UTC should default to no for most users in /etc/default/rcS
+ settimeofday() not called when UTC=yes
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

The hwclock rules should always call, whether or not UTC=yes or UTC=no, and simply use $UTC to decide whether to pass --utc or --localtime

hwclock --systz needs modifying as well, right now it never calls set_system_clock_timezone() if universal time is being used; it should anyway, and it should still call set_system_clock_timezone()

We should make sure that's safe when using UTC. I'm not sure it is right now.

Revision history for this message
Kevin Knerr (ld-barthel) wrote :

Ah! So setting UTC=no is simply a workaround for the real bug. Thanks for identifying the source of the problem so quickly.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

The first part of this has been done with the Upstart migration, we now always call hwclock --systz and simply use $UTC to decide whether to pass --utc or --localtime

Still need to make hwclock --systz --utc do something smart (right now it just returns :p)

Changed in util-linux (Ubuntu):
status: Triaged → In Progress
Changed in util-linux (Ubuntu):
assignee: nobody → Scott James Remnant (scott)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package util-linux - 2.16-1ubuntu4

---------------
util-linux (2.16-1ubuntu4) karmic; urgency=low

  * Removed access checks for hardware clock when called with --systz,
    since we may not have the rtc device at the point we run hwclock.
    I believe this is the cause of LP: #436076.
  * Set kernel timezone even when the hardware clock is in UTC.
    LP: #426886.

  * Don't step the system clock, or save the hardware clock on upgrades
    in case the time isn't quite correct. LP: #430878.
  * Remove the hwclock.sh and hwclockfirst.sh scripts on upgrades, since
    these are now Upstart jobs. LP: #434767.

 -- Scott James Remnant <email address hidden> Thu, 24 Sep 2009 12:31:29 -0700

Changed in util-linux (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.