edra:~# date
Tue Dec 12 17:40:07 CET 2006
edra:~# date
Tue Dec 12 17:40:09 CET 2006
edra:~# date
Tue Dec 12 17:40:10 CET 2006
edra:~# date
Tue Dec 12 17:40:07 CET 2006
edra:~# date
Tue Dec 12 17:40:08 CET 2006
edra:~# date
Tue Dec 12 17:40:08 CET 2006
edra:~# date
Tue Dec 12 17:40:09 CET 2006
edra:~# date
Tue Dec 12 17:40:10 CET 2006
edra:~# date
Tue Dec 12 17:40:07 CET 2006
edra:~#


never seen before something like this, any ideas?


- already tried some hwclock commands
- timezone and localtime symbolic links should be correct, also timezone (CEST)

Are these a series of commands w/o a reboot? If so, the hw clock should have nothing to do with it.

The only things I can think of is either ntpd doing something weird (if you are running it) or something really strange in your timezone file.

Do you observe the same behavior if you use the -u option to print time in UTC?

After a reboot, and after installing adjtimex the system clock has gone ok.
Before the reboot, simply, if i use date -u the time was exactly 1h past.

...there wasn't any ntpd runnging, neither crond/atd with ntpd update scripts on a faulty timeserver, simply installing adjtimex has correct the problem, or probably it was some failure of some kind.

The problem if that my opinion is that this machine is compromised... it is an university machine and some admin has put it directed connected on the internet, without a DMZ or firewall.

I've fine tuned the system time by using
#adjtimex -c -i 20
and setting the values fot tick (adjtimex -t <tick>) and frequency (adjtimex -f <freq>) as suggested by hw and system clock comparison.

Now the error_ppm is 1.3, think it's acceptable.

Thanks anyway