Weblog entry #3 for Utumno
See all weblog entries made by Utumno.
#3
Question about system time
Posted by Utumno on Sat 25 Mar 2006 at 13:35
Problem: every time I reboot, my system time gets incremented by 8 hours.
When I set up the server about 6 months ago, I think ( albeit I am not sure any more ) that I opted for 'UTC' when setting system time. Later on, I must have changed that to 'CST' ( CST = UTC - 8 hours )
Now, after a reboot,
leszek@utumno:~$ date
Sun Mar 26 5:14:53 CST 2006
The 'CST' bit assures me my timezone is set up correctly, but the 'Sun Mar 26 5:14:53' is 8 hours in the future.
Furthermore, I just rebooted a few times, each time looking at the hardware time in BIOS. Turns out after each reboot this time gets added 8 hours as well, so after n reboots my time is 8*n hours in the future.
Looks like something thinks the BIOS time is in 'UTC' timezone , then adds 8 hours to that and gets the correct 'CST' time, and saves that back to CMOS (wrong!)
for now, I've added a 'date --set='-8 hours' to an initscript, but maybe someone knows what is going on here ???
When I set up the server about 6 months ago, I think ( albeit I am not sure any more ) that I opted for 'UTC' when setting system time. Later on, I must have changed that to 'CST' ( CST = UTC - 8 hours )
Now, after a reboot,
leszek@utumno:~$ date
Sun Mar 26 5:14:53 CST 2006
The 'CST' bit assures me my timezone is set up correctly, but the 'Sun Mar 26 5:14:53' is 8 hours in the future.
Furthermore, I just rebooted a few times, each time looking at the hardware time in BIOS. Turns out after each reboot this time gets added 8 hours as well, so after n reboots my time is 8*n hours in the future.
Looks like something thinks the BIOS time is in 'UTC' timezone , then adds 8 hours to that and gets the correct 'CST' time, and saves that back to CMOS (wrong!)
for now, I've added a 'date --set='-8 hours' to an initscript, but maybe someone knows what is going on here ???
Comments on this Entry
Posted by Utumno (211.75.xx.xx) on Sat 25 Mar 2006 at 17:23
[ Send Message | View Utumno's Scratchpad | View Weblogs ]
[ Send Message | View Utumno's Scratchpad | View Weblogs ]
hmm, replying to myself, this looks like a bug in Debian. by inserting debugging echo's in various places in the initscripts, I've found the culprit: in script /etc/init.d/mountall.sh, around line 42, I've added two 'debugging echos' :
echo before mount: `date +"%F %r"` > /root/time
mount -a -v -t noproc,nfs,nfs4,smbfs,cifs,ncp,ncpfs,coda,ocfs2,gfs
ES=$?
echo after mount: `date +"%F %r"` >> /root/time
After a reboot, leszek@utumno$> cat /root/time before mount: 2006-03-29 09:08:18 AM after mount: 2006-03-29 05:08:18 PMWTF ??
[ Parent | Reply to this comment ]
Posted by Utumno (211.75.xx.xx) on Sat 25 Mar 2006 at 18:10
[ Send Message | View Utumno's Scratchpad | View Weblogs ]
[ Send Message | View Utumno's Scratchpad | View Weblogs ]
Progress. I discovered that the guilty command
actually executes those four:
and 'mount /usr' is the one which increments the time. Very odd. The only thing that comes to mind is that the timezone info is there ( /usr/share/zoneinfo/Asia/Taipei )
Having '/usr' on separate partition is legal, right?
mount -a -v -t noproc,nfs,nfs4,smbfs,cifs,ncp,ncpfs,coda,ocfs2,gfs
actually executes those four:
mount /home
mount /usr
mount /tmp
mount /var
and 'mount /usr' is the one which increments the time. Very odd. The only thing that comes to mind is that the timezone info is there ( /usr/share/zoneinfo/Asia/Taipei )
Having '/usr' on separate partition is legal, right?
[ Parent | Reply to this comment ]
Posted by Utumno (211.75.xx.xx) on Sat 25 Mar 2006 at 21:21
[ Send Message | View Utumno's Scratchpad | View Weblogs ]
[ Send Message | View Utumno's Scratchpad | View Weblogs ]
ok, I discovered http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342887.
It is a yet unresolved Debian bug. Hits people who have /usr on a separate partition and whose timezone is not UTC.
It is a yet unresolved Debian bug. Hits people who have /usr on a separate partition and whose timezone is not UTC.
[ Parent | Reply to this comment ]
Posted by Anonymous (61.11.xx.xx) on Tue 28 Mar 2006 at 08:39
Interesting bug report. I'm glad I don't have to solve the catch-22
described in it. :-)
PJ
described in it. :-)
PJ
[ Parent | Reply to this comment ]
I suffered from that same thing (although it was 4 hours, because my tz is CLT). I ended up making a very ugly hack in some obscure place in the init scripts, and finally removed it, and made a fresh install with testing. However, I had everything in one partition.
--------
Felipe Sateler
--------
Felipe Sateler
[ Parent | Reply to this comment ]
Ahhhh how nice to at least see an explaination for this annoying behavior! My manual work around for this after logging in:
# /etc/init.d/hwclockfirst.sh start
As long as hwclock is set correctly this is fine but if you fail to run /etc/init.d/hwclockfirst.sh before rebooting the hwclock is reset. I have been unsuccessful in getting this to run automatically.
# /etc/init.d/hwclockfirst.sh start
As long as hwclock is set correctly this is fine but if you fail to run /etc/init.d/hwclockfirst.sh before rebooting the hwclock is reset. I have been unsuccessful in getting this to run automatically.
[ Parent | Reply to this comment ]
Posted by Utumno (60.248.xx.xx) on Fri 31 Mar 2006 at 11:41
[ Send Message | View Utumno's Scratchpad | View Weblogs ]
[ Send Message | View Utumno's Scratchpad | View Weblogs ]
My solution ( taken from the bug report )
1) set 'TZ' ( timezone ) variable in /etc/defaults/rcS script ( in my case it is TZ="CST-8:00" )
2) bump 'hwclockfirst.sh' priority to 05 so that it runs before fsck of root partition.
Kinda sucky solution because if one ever changes his timezone, he also has to change the 'TZ' setting in the rcS script, but I dont plan on changing my timezone too often :)
Alternatively, one can just use UTC.
1) set 'TZ' ( timezone ) variable in /etc/defaults/rcS script ( in my case it is TZ="CST-8:00" )
2) bump 'hwclockfirst.sh' priority to 05 so that it runs before fsck of root partition.
Kinda sucky solution because if one ever changes his timezone, he also has to change the 'TZ' setting in the rcS script, but I dont plan on changing my timezone too often :)
Alternatively, one can just use UTC.
[ Parent | Reply to this comment ]