After Gutsy 32 to Hardy 32 upgrade Time setting fails. NTP socket is in use.

[ElZorro]

Hi I upgraded Gutsy to Hardy on a machine.
After this I could not update the system clock to the internet time server, cold not contact server error.
Sudo kcontrol from terminal reported an NTP socket in use error.

sudo /etc/init.d/ntp stop
in terminal allows the adjust clock command to work.

sudo /etc/init.d/ntp start
starts the ntpdate server again.

Does ntpdate need to run at boot or not?

If not can some script or command automatically stop it loading at boot without any detriment to the system.
I wonder what is best for accurate system time from timeserver time on Hardy.
Thanx
El Zorro

[ElZorro]

Re: After Gutsy 32 to Hardy 32 upgrade Time setting fails. NTP socket is in use.

Hmmm,
nobody else seems to suffer this particular malaise in Hardy, maybe nobody upgrades from Gutsy as an experiment.
Bit boring--- terminal---sudo /etc/init.d/ntp stop------ after every shutdown.
Trolled around, seems they had this issue in ubuntu a couple of iterations ago, but could find no fix in ubuntuland other than the boring manual thing.
Here's hoping someone knows what to do.
Cheers
El Zorro 8)

[ElZorro]

Re: After Gutsy 32 to Hardy 32 upgrade Time setting fails. NTP socket is in use.

Oh well ,
" How to NTP" from the Gentoo has quite an informative voluminous post that may help solve this problem, as there seems precious little on it in Kubuntu or Ubuntu.
So when I have time, no quick fixes so far.
Cheers
El Zorro 8)

[daihard]

Re: After Gutsy 32 to Hardy 32 upgrade Time setting fails. NTP socket is in use.

Oh well ,
" How to NTP" from the Gentoo has quite an informative voluminous post that may help solve this problem, as there seems precious little on it in Kubuntu or Ubuntu.
So when I have time, no quick fixes so far.
Cheers
El Zorro 8)

I am not sure I understand what your problem is. The ntp daemon does contact the specified NTP server and adjusts the system time, so there's no need to run "ntpdate" manually.

For an experiment, I stopped the ntp daemon and ran ntpdate against an external NTP server in this area. The system clock was only 0.003084 second off, which leads me to believe the ntp daemon is doing its job properly.