Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm using the latest version of Proxmox VE (which is based on Debian) and I can't fix the wrong time problem:

$ pveversion -v
pve-manager: 1.7-11 (pve-manager/1.7/5470)
running kernel: 2.6.32-4-pve
proxmox-ve-2.6.32: 1.7-30
pve-kernel-2.6.32-4-pve: 2.6.32-30
qemu-server: 1.1-28
pve-firmware: 1.0-10
libpve-storage-perl: 1.0-16
vncterm: 0.9-2
vzctl: 3.0.24-1pve4
vzdump: 1.2-10
vzprocps: 2.0.11-1dso2
vzquota: 3.0.11-1
pve-qemu-kvm: 0.13.0-3
ksm-control-daemon: 1.0-4

The host system's time is:

$ date
Fri Feb 25 12:39:12 CET 2011

but this is wrong because the correct time should be

Fri Feb 25 11:39:12 CET 2011

Because that's the local time in Belgium (where that server is located).

The timezone of the proxmox host is:

$ cat /etc/timezone 
Europe/Brussels

And there was no timezone setting in the server's BIOS settings. The server's BIOS screen shows the time correctly. I also receive the following warning from the system:

warning: `ntpd' uses 32-bit capabilities (legacy support in use)

According to /etc/default/rcS:

TMPTIME=0
SULOGIN=no
DELAYLOGIN=no
UTC=no
VERBOSE=no
FSCKFIX=no
RAMRUN=no
RAMLOCK=no

(Previously it was UTC=yes and I changed it into UTC=no and rebooted the server, hoping it would help but nothing changed.)

The ntp daemon is running and I did not make any changes to any ntp configuration file, they are at proxmox defaults.

How can I fix this wrong time issue?

share|improve this question

1 Answer 1

up vote 1 down vote accepted

What does

/usr/sbin/ntpq -p

show?

Try doing

sntp -P no -r pool.ntp.org

to set the time right and do afterwards a

hwclock --systohc

to write the time to the hardware clock.

share|improve this answer
    
$ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== ns.ttosi.net .INIT. 16 u - 1024 0 0.000 0.000 0.000 79.99.122.30 .INIT. 16 u - 1024 0 0.000 0.000 0.000 xen02.cblue.be .INIT. 16 u - 1024 0 0.000 0.000 0.000 ns2.ttosi.net .INIT. 16 u - 1024 0 0.000 0.000 0.000 –  Emre Sevinç Feb 25 '11 at 12:51
    
I had to install msntp package because I could not find anything starting with sntp. Anyway running msntp -P no -r pool.ntp.org just led to a long long wait so I had to Ctrl-c it. On the other hand when I did dpkg-reconfigure tzdata and then selected None of the above and then UTC it started to show the correct time. However I don't know if this is the right thing to do, e.g. changing the timezone from Europe/Brussels to Etc/UTC. On other Linux systems I used (mostly Ubuntu) I set the timezone according to the geographical location and did not encounter any problems. That's why I'm confused. –  Emre Sevinç Feb 25 '11 at 12:52
    
Apparently the NTP port 123 was blocked on the firewall, the problem is solved after port 123 is opened. Thanks for the detailed answer. –  Emre Sevinç Feb 25 '11 at 15:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.