Problem setting date/time in Debian etch

[reunis]

Hi all,

I am a novice part-time Debian (etch) admin. I noticed that my server's time is not correct, so started googling up what I can do about it. Found out about ntpd, ntpdate and the date command. All of these I could operate seemingly without any trouble, however my problem is that the time still does not actually change!

Maybe easiest to put like this -- what is wrong here:

jenkins:~# whoami
root
jenkins:~# date --set=18:00:00; date
Sun Nov 9 18:00:00 EET 2008
Sun Nov 9 18:24:22 EET 2008
jenkins:~# date --set=19:00:00; date
Sun Nov 9 19:00:00 EET 2008
Sun Nov 9 18:24:26 EET 2008
jenkins:~# date
Sun Nov 9 18:24:28 EET 2008
jenkins:~#

The server is a virtual one that we're renting from a service provider.

I find it difficult to even figure out what additional information I could provide that might help solve my issue.

-reunis

[Darkhellzz]

hi you try


date --set 18:00:01

Then it will work

[reunis]

Well already tried that, doesn't seem to help:

jenkins:~# date --set 18:00:01; date
Sun Nov 9 18:00:01 EET 2008
Sun Nov 9 18:33:08 EET 2008
jenkins:~# date --set 18:00:01
Sun Nov 9 18:00:01 EET 2008
jenkins:~# date
Sun Nov 9 18:33:14 EET 2008
jenkins:~#

Or did I misunderstand something?

[reunis]

As said, I also tried first ntpd and then ntpdate, but can't get them to update the time either... So I think it should be something beyond the syntax of the date command?

jenkins:~# ntpdate -b 0.debian.pool.ntp.org; date
9 Nov 19:02:17 ntpdate[19857]: step time server 87.108.20.69 offset -962.055469 sec
Sun Nov 9 19:02:17 EET 2008
jenkins:~# ntpdate -b 0.debian.pool.ntp.org; date
9 Nov 19:02:21 ntpdate[19859]: step time server 87.108.20.69 offset -962.055899 sec
Sun Nov 9 19:02:21 EET 2008
jenkins:~# ntpdate -b 0.debian.pool.ntp.org; date
9 Nov 19:02:25 ntpdate[19863]: step time server 213.255.167.69 offset -962.059927 sec
Sun Nov 9 19:02:25 EET 2008

Can there be some lower-level issue that prevents even root from changing the time? Would be great to actually see some error message, even a not-that-informative one...

[Freston]

Pfff, grrrr

All I think is, why don't I have this issue?? This should be as easy as pie.

Do you have some remote time server or something?? Being 'root' is only one part in the equation. There's probably something unique to your system config preventing change in time.

[RumbleFish]

I think your problem is that ntpdate is 'slewing' the time rather than setting the time to the proper one.
From the 'ntpdate' man page

"Time adjustments are made by ntpdate in one of two ways. If ntpdate determines the clock is in error more than 0.5 second it will simply step the time by calling the system settimeofday() routine. If the error is less than 0.5 seconds, it will slew the time by calling the system adjtime() routine. The latter technique is less disruptive and more accurate when the error is small, and works quite well when ntpdate is run by cron every hour or two."

Since your time is out by minutes and since Unix does not like sudden time changes ntpdate will slowly correct the time a few seconds every minute.

If you want to suddenly change the time to the correct time you need to use the '-b' switch with 'ntpdate'.

Since you have a large negative time step I would recommend that you shutdown to single user and then set the time.

[reunis]

Many thanks for the suggestions, however the problem is still there.

@Freston: I agree, there has to be something unique. Can it be related to the fact that it's a virtual server? I wish I could tell where to start looking for a clue regarding the unique thing I have; as said, an error message would be great. As far as I can tell, it's a vanilla etch system (pre-installed by the service provider) where I've added only some very mature software such as CVS.
I don't exactly know what you mean by remote time server (as said, I set up ntpd myself; it wasn't pre-installed), but I think if there was some mechanism already taking care of time, then I wouldn't even need to bother... But it's currently about 17 minutes off, and the difference to actual time is just increasing.

@RumbleFish: Actually, I did use the '-b' switch, as you can see from my previous post. And even if I didn't, the date command should've done the same, right?
I understand that it's better to adjust the time using small steps and that's what ntpd is supposed to do as well, however that method is not really changing the time either:

jenkins:~# date; ntpq -pn
Mon Nov 10 10:01:58 EET 2008
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+81.209.33.131   78.187.118.69    4 u   26   64  377    6.577  -969000  18.733
*193.65.58.58    62.119.40.98     2 u   40   64  377    1.649  -968996  30.213
+193.65.58.57    193.204.114.233  2 u   15   64  377    1.838  -969016  20.819
+81.22.244.161   192.36.133.25    2 u   41   64  377    0.467  -968990  37.183
jenkins:~# 
jenkins:~# date; ntpq -pn
Mon Nov 10 10:08:48 EET 2008
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-81.209.33.131   78.187.118.69    4 u   49   64  377    6.707  -969059  27.010
+193.65.58.58    62.119.40.98     2 u   62   64  377    1.852  -969081  24.601
+193.65.58.57    193.204.114.233  2 u   36   64  377    1.705  -969099  37.476
*81.22.244.161   192.36.133.25    2 u   64   64  377    0.498  -969065  21.010

[reunis]

Tried to call settimeofday directly to get an error, but that didn't really help either:

jenkins:~/timetest# cat timetest.c 
#include <sys/time.h>
#include <stdio.h>
 
main() {
  int ret;
  struct timeval tv;
  struct timezone tz;
  ret = gettimeofday(&tv, &tz);
  if (ret == 0) {
    printf("before: gettimeofday returns %d seconds\n", tv.tv_sec);
    printf("about to adjust by -900 seconds...\n");
    tv.tv_sec -= 900;
    ret = settimeofday(&tv, &tz);
    printf("settimeofday's return value was %d\n", ret);
    ret = gettimeofday(&tv, &tz);
    if (ret == 0) {
      printf("after: gettimeofday returns %d seconds\n", tv.tv_sec);
    }
  }
}
jenkins:~/timetest# gcc timetest.c 
jenkins:~/timetest# ./a.out 
before: gettimeofday returns 1226306031 seconds
about to adjust by -900 seconds...
settimeofday's return value was 0
after: gettimeofday returns 1226306031 seconds
jenkins:~/timetest#

Meaning that time does not change, even though settimeofday returns success.

The problem has to be in the virtualization environment, on a level that I cannot reach, right?

[RumbleFish]

Oops! I must have missed the 'ntpdate -b' option

Check to see if your hardware clock matches your software clock.

# hwclock --show
# date

They don't have to be exact just close.

It may be that you set the software clock with 'ntpdate' but the hardware clock doesn't get set.

If the time between the hardware and software clock is way off then you may have a bad/buggy harware clock.

You can manually set with

# hwclock --systohc

[jledhead]

I wouldn't think this has anything to do with virtualization. is there an ntpdate service running? if so kill it and then try and set the time.