Public bug reported: Binary package hint: upstart-compat-sysv
It is common to have /usr as a mountpoint, Ubuntu depends on files on /usr before /etc/rcS.d/S35mountall while booting. This can lead to a misset system clock it the hardware clock is not running at UTC. Ubuntus default sets the hardware clock to local time. It is documented in man rcS that /etc/localtime should not be a symlink to /usr/share/zoneinfo/$region/$file if (1) /usr is not available at boot and (2) the hardware clock is not UTC, because hwclock --hwtosys depends on zoneinfo to get correct timezone and daylightsaving information. While booting /etc/rcS.d/S10udev is run early. /etc/udev/rules.d/85-... files have references to /usr binaries. /etc/udev/rules.d/85-ifupdown now handles network interfaces through ifup, this calls /usr/bin/ntpdate to set the system clock to network time. But /etc/udev/rules.d/85-hwclock tries also to set the system clock from the build in hardware clock. /etc/rcS.d/S11hwclock sets it a third time after udev. In the standard case where /usr is no mountpoint and thus available, this overwrites the ntpdate corrected system time with the hardware time. This is wrong behaviour anyway. But in the case of an unavailable /usr /etc/rcS.d/S11hwclock fails to determine the timezone and assumes hardware clock runs UTC, ending up with a wrong system time. When arriving at /etc/rcS.d/S40networking the interfaces are already up because of udev and thus /etc/network/if- up.d/$scripts are not run again, so ntpdate never corrects the time until maybe networkmanager calls it again. But people with a static network config do not need nm. Workarounds are: (1) to mv /etc/rcs.d/S11hwclock.sh /etc/rcS.d/38hwclock.sh so it is run afer /etc/rcS.d/35mountall or (2) to copy the localtime file from /usr/share/zoneinfo/$region/$file to /etc/localtime. This sets correct timezone and time from the hardware clock at boot. (1) ntpdate could be installed to /bin/ or (2) called through /etc/rc.local This sets network time at boot. The S08hwclockfirst.sh script checks readability of /etc/localtime, S11hwclock.sh just sets the system clock, even if that file is not readable, so it seems to be the purpose of S11hwclock.sh to be run later after mountall. chmod 000 /etc/udev/85-ifupdown also sets network time during boot because /etc/rcS.d/S40networking brings up the interfaces instead. It is still an issue that the hardware clock is not set to system time upon hibernate https://bugs.launchpad.net/ubuntu/+source/acpi- support/+bug/36815, this can cause troubles during daylight saving transitions. So it is fine to set the hardware clock with a daily cron after the system clock has correct network time: sudo sh -c 'echo "#!/bin/sh \n/usr/sbin/ntpdate-debian -b -s 2>/dev/null \n/usr/sbin/invoke-rc.d hwclock.sh restart >/dev/null 2>&1 \ndrift=\$(cut /etc/adjtime -d'\'' '\'' -s -f 1)\ndatestr=\$(cut /etc/adjtime -d'\'' '\'' -s -f 2)\ndate=\$(date [EMAIL PROTECTED])\nmode=\$(tail -n -1 /etc/adjtime)\nlogger -t hwclock -- RTC running at \${mode} synchronized to date: \${date}\; systematic drift \${drift} s/day" > /etc/cron.daily/sethwclock';sudo chmod 755 /etc/cron.daily/sethwclock This sets the correct time from network every day to both clocks. It could also be possible to mount /usr -oro in say S05mountusr and umount /usr again S29umountusr before S30checkfs, but normally early boot should not depend on /usr. Maybe including fsck and mount in udev is an option. ** Affects: upstart (Ubuntu) Importance: Undecided Status: New ** Description changed: Binary package hint: upstart-compat-sysv It is common to have /usr as a mountpoint, Ubuntu depends on files on /usr before /etc/rcS.d/S35mountall while booting. This can lead to a misset system clock it the hardware clock is not running at UTC. Ubuntus default sets the hardware clock to local time. It is documented in man rcS that /etc/localtime should not be a symlink to /usr/share/zoneinfo/$region/$file if (1) /usr is not available at boot and (2) the hardware clock is not UTC, because hwclock --hwtosys depends on zoneinfo to get correct timezone and daylightsaving information. While booting /etc/rcS.d/S10udev is run early. /etc/udev/rules.d/85-... files have references to /usr binaries. /etc/udev/rules.d/85-ifupdown now handles network interfaces through ifup, this calls /usr/bin/ntpdate to set the system clock to network time. But /etc/udev/rules.d/85-hwclock tries also to set the system clock from the build in hardware clock. /etc/rcS.d/S11hwclock sets it a third time after udev. In the standard case where /usr is no mountpoint and thus available, this overwrites the ntpdate corrected system time with the hardware time. This is wrong behaviour anyway. But in the case of an unavailable /usr /etc/rcS.d/S11hwclock fails to determine the timezone and assumes hardware clock runs UTC, ending up with a wrong system time. When arriving at /etc/rcS.d/S40networking the interfaces are already up because of udev and thus /etc/network/if- up.d/$scripts are not run again, so ntpdate never corrects the time until maybe networkmanager calls it again. But people with a static network config do not need nm. Workarounds are: (1) to mv /etc/rcs.d/S11hwclock.sh /etc/rcS.d/38hwclock.sh so it is run afer /etc/rcS.d/35mountall or (2) to copy the localtime file from /usr/share/zoneinfo/$region/$file to /etc/localtime. This sets correct timezone and time from the hardware clock at boot. (1) ntpdate could be installed to /bin/ or (2) called through /etc/rc.local This sets network time at boot. The S08hwclockfirst.sh script checks readability of /etc/localtime, S11hwclock.sh just sets the system clock, even if that file is not readable, so it seems to be the purpose of S11hwclock.sh to be run later after mountall. chmod 000 /etc/udev/85-ifupdown also sets network time during boot because /etc/rcS.d/S40networking brings up the interfaces instead. It is still an issue that the hardware clock is not set to system time upon hibernate https://bugs.launchpad.net/ubuntu/+source/acpi- - support/+bug/36815, this can cause troubles during daylight saving - transitions. So it is fine to set the hardware clock with a daily cron - after the system clock has correct network time: + support/+bug/36815,[bug]36815[\bug] this can cause troubles during + daylight saving transitions. So it is fine to set the hardware clock + with a daily cron after the system clock has correct network time: sudo sh -c 'echo "#!/bin/sh \n/usr/sbin/ntpdate-debian -b -s 2>/dev/null \n/usr/sbin/invoke-rc.d hwclock.sh restart >/dev/null 2>&1 \ndrift=\$(cut /etc/adjtime -d'\'' '\'' -s -f 1)\ndatestr=\$(cut /etc/adjtime -d'\'' '\'' -s -f 2)\ndate=\$(date [EMAIL PROTECTED])\nmode=\$(tail -n -1 /etc/adjtime)\nlogger -t hwclock -- RTC running at \${mode} synchronized to date: \${date}\; systematic drift \${drift} s/day" > /etc/cron.daily/sethwclock';sudo chmod 755 /etc/cron.daily/sethwclock This sets the correct time from network every day to both clocks. It could also be possible to mount /usr -oro in say S05mountusr and umount /usr again S29umountusr before S30checkfs, but normally early boot should not depend on /usr. Maybe including fsck and mount in udev is an option. ** Description changed: Binary package hint: upstart-compat-sysv It is common to have /usr as a mountpoint, Ubuntu depends on files on /usr before /etc/rcS.d/S35mountall while booting. This can lead to a misset system clock it the hardware clock is not running at UTC. Ubuntus default sets the hardware clock to local time. It is documented in man rcS that /etc/localtime should not be a symlink to /usr/share/zoneinfo/$region/$file if (1) /usr is not available at boot and (2) the hardware clock is not UTC, because hwclock --hwtosys depends on zoneinfo to get correct timezone and daylightsaving information. While booting /etc/rcS.d/S10udev is run early. /etc/udev/rules.d/85-... files have references to /usr binaries. /etc/udev/rules.d/85-ifupdown now handles network interfaces through ifup, this calls /usr/bin/ntpdate to set the system clock to network time. But /etc/udev/rules.d/85-hwclock tries also to set the system clock from the build in hardware clock. /etc/rcS.d/S11hwclock sets it a third time after udev. In the standard case where /usr is no mountpoint and thus available, this overwrites the ntpdate corrected system time with the hardware time. This is wrong behaviour anyway. But in the case of an unavailable /usr /etc/rcS.d/S11hwclock fails to determine the timezone and assumes hardware clock runs UTC, ending up with a wrong system time. When arriving at /etc/rcS.d/S40networking the interfaces are already up because of udev and thus /etc/network/if- up.d/$scripts are not run again, so ntpdate never corrects the time until maybe networkmanager calls it again. But people with a static network config do not need nm. Workarounds are: (1) to mv /etc/rcs.d/S11hwclock.sh /etc/rcS.d/38hwclock.sh so it is run afer /etc/rcS.d/35mountall or (2) to copy the localtime file from /usr/share/zoneinfo/$region/$file to /etc/localtime. This sets correct timezone and time from the hardware clock at boot. (1) ntpdate could be installed to /bin/ or (2) called through /etc/rc.local This sets network time at boot. The S08hwclockfirst.sh script checks readability of /etc/localtime, S11hwclock.sh just sets the system clock, even if that file is not readable, so it seems to be the purpose of S11hwclock.sh to be run later after mountall. chmod 000 /etc/udev/85-ifupdown also sets network time during boot because /etc/rcS.d/S40networking brings up the interfaces instead. It is still an issue that the hardware clock is not set to system time upon hibernate https://bugs.launchpad.net/ubuntu/+source/acpi- - support/+bug/36815,[bug]36815[\bug] this can cause troubles during - daylight saving transitions. So it is fine to set the hardware clock - with a daily cron after the system clock has correct network time: + support/+bug/36815, this can cause troubles during daylight saving + transitions. So it is fine to set the hardware clock with a daily cron + after the system clock has correct network time: sudo sh -c 'echo "#!/bin/sh \n/usr/sbin/ntpdate-debian -b -s 2>/dev/null \n/usr/sbin/invoke-rc.d hwclock.sh restart >/dev/null 2>&1 \ndrift=\$(cut /etc/adjtime -d'\'' '\'' -s -f 1)\ndatestr=\$(cut /etc/adjtime -d'\'' '\'' -s -f 2)\ndate=\$(date [EMAIL PROTECTED])\nmode=\$(tail -n -1 /etc/adjtime)\nlogger -t hwclock -- RTC running at \${mode} synchronized to date: \${date}\; systematic drift \${drift} s/day" > /etc/cron.daily/sethwclock';sudo chmod 755 /etc/cron.daily/sethwclock This sets the correct time from network every day to both clocks. It could also be possible to mount /usr -oro in say S05mountusr and umount /usr again S29umountusr before S30checkfs, but normally early boot should not depend on /usr. Maybe including fsck and mount in udev is an option. -- udev can lead to wrong system time https://bugs.launchpad.net/bugs/160197 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
