Issue with time

[MSCFAdmin]

I am installing FreeNAS 8.2.0 in a Windows Active Directory network. At the moment, I have not changed any settings except the root password. I am trying to connect to the active directory, but it says my time is off. I set my time server to be the main NTP server on our network but it tells me it can't connect. However, in the shell I can ping that server. I can also run ntpdc > dmpeers and get the following:

remote local st poll reach delay offset disp
=======================================================================
10.161.*** 10.161.*** 1 64 377 0.00031 2483.1490 0.12845

So it almost looks like NTP is working. But my time is constantly off by about 56 minutes. I can't find anywhere to manually set the time in order to get this up and running temporarily.

 

[ProtoSD]

Possibly you need to check your timezone in settings?

 

[MSCFAdmin]

It is set correctly.

 

[MSCFAdmin]

I was able to get it joined by manually setting the date with the date command. However, it seems to still be having issues with ntp syncing.

 

[jgreco]

The offset in your dmpeers output indicates a significant offset from the NTP server. It's not 56 minutes, but it's quite a few. Time or NTP is not working correctly for you.

Experiment:

Try turning off ntpd. Run "date" at the command prompt. Set a timer for an hour. When it goes off, run "date" at the command prompt again. If the difference in times isn't an hour, you have some hardware clock issue that's causing FreeBSD to not keep accurate time. There are possible ways to fix this. I'm guessing this is what's happening to you, but I could be wrong, so write back either way.

 

[survive]

Hi MSCFAdmin,

For grins you could add a couple more time servers to your freenas box & see if they can't average out to something more sane. Here's a link to the ntp.org public servers page:

http://support.ntp.org/bin/view/Servers/NTPPoolServers

-Will

 

[winstontj]

I'm in a similar situation.

It didn't fix my issue but I finally figured out that the time in the system BIOS was not the same as the time in the OS and that change allowed me to make some progress.

Make sure the BIOS time matches the OS time.

 

[MSCFAdmin]

@jgreco - I used "date" to set it even with my time server earlier today to get it on the domain, and I just ran it again and the time drift is about 2 minutes.

 

[MSCFAdmin]

@survive - I had 3 time servers in there at one point and that didn't help at all. Same strange offset.

 

[survive]

Hi MSCFAdmin,

I'm not sure this will answer your question, but you can use the "ntpdate" command to sync the clock to an ntp server...basically it's an automated "date" command. Use "ntpdate -b <ntp_server>" to force the clock to sync immediately (usually the clock will slowly sync up so the time doesn't seem to change a huge amount). You might need to stop the ntp service to run ntpdate as they both use the same port.

It might be you just need to get your clock synced up enough for ntp to take over & the ntpdate command should do that for you.

-Will

 

[flojo]

I wonder if that is not a bug with 8.2.

Try 8.3 ( http://sourceforge.net/projects/freenas/files/FreeNAS-8-nightly/ ).

 

[jgreco]

If FreeNAS isn't doing an explicit clock sync to your NTP servers while it is starting up, that should be considered a bug. ntpdate is deprecated and shouldn't be used any longer, ntpd is capable of doing the Right Things(tm) if suitably used.

 

[MSCFAdmin]

I tried to use ntpdate, but it says it can't connect to the server. But then I can ping the server:

[root@freenas ~]# ntpdate
28 Jul 08:38:55 ntpdate[43360]: no servers can be used, exiting
[root@freenas ~]# ping clinton
PING clinton.fakedomainname.local (10.161.***): 56 data bytes
64 bytes from 10.161.***: icmp_seq=0 ttl=128 time=1.018 ms
64 bytes from 10.161.***: icmp_seq=1 ttl=128 time=0.230 ms
^C
--- clinton.fakedomainname.local ping statistics ---

 

[survive]

Hi MSCFAdmin,

Then point ntpdate to one of the public servers in post#6 above. All you want is to get your clock synced\correct this one time so we can see if you start syncing with your local server once the system's time has been corrected.

Try this command "ntpdate -b 0.pool.ntp.org"

-Will

 

[MSCFAdmin]

@survive - When I try that I get:
ntpdate -b 0.pool.ntp.org
28 Jul 13:49:28 ntpdate[46367]: the NTP socket is in use, exiting

 

[MSCFAdmin]

@jgreco - Is there something I can try with ntpd? I tried just entering "ntpd" and the following appeared in the status window:
Jul 28 13:49:19 freenas ntpd[46362]: ntpd 4.2.4p5-a (1)
Jul 28 13:49:19 freenas ntpd[46363]: unable to bind to wildcard socket address 0.0.0.0 - another process may be running - EXITING

 

[jgreco]

@survive - I had 3 time servers in there at one point and that didn't help at all. Same strange offset.

Yeah, it's not going to, usually. If there's a system problem, then ntpd just can't do its thing quite right. More servers doesn't fix that. More servers only helps if the upstream server is screwed in the head somehow. Are you seeing anything in the log? A time drift of two minutes over what's presumably a few hours is within the realm of what ntpd ought to be able to correct. If it's off two minutes within the period of an hour, that might be too much. Post your motherboard make and model (or Google for it along with "freebsd" and "time") and we can go from there.

 

[MSCFAdmin]

It is actually running on VMWare ESXi, so it should be hardware independent. I did double check that my VM bios is not using HPET.

 

[jgreco]

Ooooooh. Hm. Now that adds some complication, because ESXi doesn't provide the hardware stability FreeBSD and ntpd expect by default on a real hardware platform.

Try adjusting hint.apic.0.disabled=1 and kern.hz=100 and see if that helps. It's an older fix but sometimes still helps.

 

[MSCFAdmin]

I'm really new to FreeBSD, where would I edit those?