[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Follow Up: Re: date broken in coreutils-6.7 and new glibc-2.7
From: |
Philip Rowlands |
Subject: |
Re: Follow Up: Re: date broken in coreutils-6.7 and new glibc-2.7 |
Date: |
Mon, 12 Nov 2007 19:01:09 +0000 (GMT) |
On Mon, 12 Nov 2007, Clemens Koller wrote:
As already mentioned, my problem is that I cannot set the date
reliably, working on glibc-2.7 and coreutils-6.9 (including the
futimens patch). I did some more tests (the commands have been entered
one by one... only some second(s) in between):
Right after power-up, login:
address@hidden:~$ date
Thu Jan 1 01:00:00 CET 1970
address@hidden:~$ date -u 111214492007.00
Mon Nov 12 14:49:00 UTC 2007
address@hidden:~$ date
Thu Jan 1 01:00:00 CET 1970
This is wrong.
[snip repeats]
address@hidden:~$ date -u 111214492007.00
Mon Nov 12 14:49:00 UTC 2007
address@hidden:~$ date
Thu Jan 1 01:00:00 CET 1970
address@hidden:~$ date
Mon Nov 12 15:49:03 CET 2007 <<< working from here!!
Well, that's odd.
An then another test-run after some minutes uptime, everything is fine:
address@hidden:~$ date
Mon Nov 12 16:04:11 CET 2007
address@hidden:~$ date -s 16:06
Mon Nov 12 16:06:00 CET 2007
I think I forgot to mention that the problem seems to appear only
right after powerup of the embedded device (it has a RTC on it's I2C
bus (DS1337U chip) but that's not used here or broken).
The interesting part of it is, that the date can indeed be set with -u
(and with -s), but the actual update seems to be delayed by about one
minute after a reboot. Once the system is up and the date has been set
once, it can be set properly without any delay or problem.
It seems more kernel / glibc related to me, now. And I will have to
first understand the expected behaviour of the kernel. (But note: the
kernel didn't change in between my toolchain upgrade, so it was
working before with the old glibc-2.3.5, same coreutils... ????)
It certainly sounds like a problem with the kernel/RTC interaction. I
don't know the history of glibc changes with regard to time functions.
Below are some strace outputs... in case of interest.
-------------------------8<---------------------------
WORKING PROPERLY (I want to set it back 2 minutes):
$ date -s 16:12;date;strace date -s 16:10;date
Mon Nov 12 16:12:00 CET 2007
Mon Nov 12 16:12:00 CET 2007
execve("/bin/date", ["date", "-s", "16:10"], [/* 19 vars */]) = 0
clock_gettime(CLOCK_REALTIME, {1194880320, 18361000}) = 0
open("/etc/localtime", O_RDONLY) = 3
read(3, "\nCET-1CEST,M3.5.0,M10.5.0/3\n", 4096) = 28
clock_settime(CLOCK_REALTIME, {1194880200, 0}) = 0
write(1, "Mon Nov 12 16:10:00 CET 2007\n", 29) = 29
I removed the uninteresting strace lines, and what's left looks fine.
Just after a reboot - NOT WORKING:
(because I want to set it to 15:10 CET and not to 15:12 UTC)
address@hidden:~$ date -u 111215122007.00;date;strace date -s
111215102007.00;date
Mon Nov 12 15:12:00 UTC 2007
Mon Nov 12 16:12:00 CET 2007
execve("/bin/date", ["date", "-s", "111215102007.00"], [/* 19 vars */]) = 0
write(2, "date: ", 6) = 6
write(2, "invalid date `111215102007.00\'", 30) = 30
write(2, "\n", 1) = 1
close(1) = 0
close(2) = 0
This fails for a different reason; the format is incorrect unless using
the -u flag. This really isn't obvious from the documentation, and may
be a bug; the only thing -u is supposed to do is provide an implicit
TZ=UTC0 environment variable.
But back to the problem at hand. It's obvious something is wrong with
setting the date on your system, but to conclusively show where the
problem lies, could you provide strace output showing the set followed
by get? Do not alter the arguments to the failing date command, just run
something like:
# strace -e clock_gettime,clock_settime date -u 111214492007.00
# strace -e clock_gettime date
which was the failing example above. If the clock_gettime() does not
return a value very close to the clock_settime() just called, you have a
kernel bug (or a malicious process running separately).
Cheers,
Phil