NTP clock sync
-
That is so strange. Something on your network is killing NTP. Has to be.
Its not broken here. Did you select WAN as interface and save? And you entered DNS servers? And you have NTP server address entered?
-
Something on your network is killing NTP. Has to be.
I very much doubt that (no such indication on any other system in the network) and even if it was, the result in pfSense should only be no contact (or in some other way a non-functional ntp), not that the service totally fail to start.
Regardless of whatever specific things I (and owner524 and val) have in the setup that causes issues, the service should still be starting. I tend to think it is a bug, that is only showing under some specific conditions.
It would probably be very useful if the other users reporting problems here could explain about their respective configurations. Maybe we could find out what we have in common that may cause the issue?
In addition to what I have reported so far in the thread, I can add that it is a full 64 bit install and I used the FreeBSD 64 bit template, gave it 3 bridged network interfaces, 2 cpus and 4011 MB RAM in VirtualBox.
Its not broken here.
Yes it seems only a few of us are having this issue.
Did you select WAN as interface and save?
Well I have to select both WAN and LAN since I have both my own and public ntp servers configured but there is no change in behaviour. And really, not selecting any interface does mean all interfaces are used, if I understand things correctly? If so it should be more forgiving, if anything, to not select any interface.
Only selecting the WAN interface means also that in your local network you cannot use the pfSense as an ntp server serving your internal network, doesn't it?
By my trial and error testing, I'm under the impression that the ntp server interface selection does limit the interface usage both for when the ntp service connects to other servers and also for serving ntp clients.
And you entered DNS servers?
Yes and it is working.
And you have NTP server address entered?
Yes, remember that when I use the manual workaround reported earlier (press the Save button on the System, General Setup page), so far the service have started every time and then it works.
-
So the process crashes, or???
-
Yes, it appears that way. When I logged in today the ntp service was once again stopped. I've attached the last of my ntp log…
-
SIGTERM does not sound like crash. Something is telling ntpd to terminate.
-
Okay.
At least it's not me… ;D
-
Look in the system log around the time of the "signal 15" NTPD exit. Hopefully there was some interesting other activity - link down/up, VPN down/up , something that might give a clue as to why NTPD is being told to stop. Then the question is, why is it not started again, or what goes wrong whne the system does try to start it again?
-
I logged in at 15:05:33. After that the system log looks like this:
-
Entirely different one, it crashed… should leave a core dump somewhere hopefully.
-
I did a fresh reinstall of PFSense and it still does it. crash's everytime
-
In services > NTPD, try selecting just one interface (e.g. LAN) and see if it stays up.
-
I think I tried that earlier but to make really sure I now run it with only the WAN interface selected and the same thing happens.
-
Yep - Its a dicfer.
-
could this be fixed?
-
No, not without someone providing the core dumps at least.
-
"In addition to what I have reported so far in the thread, I can add that it is a full 64 bit install and I used the FreeBSD 64 bit template, gave it 3 bridged network interfaces, 2 cpus and 4011 MB RAM in VirtualBox."
Just for giggles… Can you try the same thing with a i386 32bit version? Clean install and restore settings. This could also be a virtualization issue.
-
Can you try the same thing with a i386 32bit version? Clean install and restore settings.
Works. At least it have started properly following 4 reboots, which have never happened with my 64 bit VM.
This could also be a virtualization issue.
Possible but I would imagine more than me today run pfSense in VirtualBox…
-
I had a similar failure under ESXi but my mind was not focusing on the NTP issue because the AMD64 version was also breaking my interfaces under ESXi…
I would have thought of this earlier, but I wasn't tipsy earlier ;D
-
No, not without someone providing the core dumps at least.
I wasn't aware that someone wanted it.
In addition to that, I am not at all familiar with the procedure so I will need some guidance… :-\
-
Is it broken again? ???