Re: Follow Up: Re: date broken in coreutils-6.7 and new glibc-2.7

[Philip Rowlands]

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