Upgrade to 2.1 ntpd service have to manually start each time now.
-
And 64bit I take it?
It can take a while to start though the switch from openntp to ntp.org helped matters considerably. This is especially true if upstream connectivity is bad.
Steve
-
Yes 64bit
LOL Like you say must take a while it's working now on the upgraded one I had, but not on the fresh install.
Anyways thanks for your help :)
-
Yeah, ntpd works to it's own special time scale! ::)
It doesn't start replying to ntp requests until it is satisfied that its upstream servers are giving it a correct and good quality time. Hence if it doesn't have many to look at or some of them are not replying etc it can take a while.Steve
-
Yes - But that doesn't explain why its a piece of crap under virtualized 64 bit installs but not under 32 bit installs or 2.03. I'm sure its on the short list of things to tweak for next patch.
-
Has been flaky on my 64-bit bare metal (ie, not virtual) install since 2.1 upgrade - including several times of it started after reboot, but expired and did not restart some time later, until I manually kicked it. Yes, running squid.
Oct 3 02:26:17 kernel: pid 76435 (ntpd), uid 0: exited on signal 11 (core dumped) Oct 3 02:48:59 kernel: pid 75268 (ntpd), uid 0: exited on signal 11 (core dumped) Oct 4 14:19:59 php: /status_services.php: NTPD is starting up. Oct 5 11:28:00 kernel: pid 1546 (ntpd), uid 0: exited on signal 11 (core dumped) Oct 5 12:52:38 php: /status_services.php: NTPD is starting up.Which I suppose means I have some core dumps somewhere.
The last one is a "crapped out at reboot", the first two the system claimed to be up, and had been for days. It hadn't restarted when I noticed it was not working 36 hours or so later and kicked it. Both the startups are manual.
-
Yeah - I don't need enormous memory here, so 32bit works fine in VM. I run straight hardware here at the house and 64bit is great.
Its seems its the 64bit + Virtualization combo thats a issue. I'm not too worried long term. I'm sure it will be part of the very first patch to 2.1 -
I'm curious for those who are seeing the crashes still, or failures to start, if you have selected specific binding interfaces to by used by NTP, or if you have -no- interfaces selected.
If you have something selected, ctrl-click until nothing is selected, save, and try it that way.
-
I just noticed that I am having NTP issues. I got a crash (error 11) last night around 1AM ET, and restarted the service. I check again this AM around 10 AM ET, and the service was stopped, nothing in the logs to indicate a crash.
Bound to my WAN2 interface. That interface went down a couple of days ago, not sure if that caused the issue.
-
I've had no trouble at all with NTP in a 64-bit VM. It's been running for months on 2.1 beta/RC releases and, now, on a fresh install with restored config.
So, having said that, now waiting for it to crash :)
-
unselected as jimp suggested a few days ago.
Had to restart due to cable-modem issues (or I could say, restarted the pfsense, and that didn't work, so next I restarted the cable modem and that did work.) NTP did not start on restart, but that might have been due to the cable modem issue continuing at that point.
-
I installed the Service Watchdog package to help deal with this random NTP issue. Hopefully this will band-aid the problem until the exact cause is determined.
-
I'm seeing it crash within seconds of starting it. I'm on 64-bit bare metal v2.1. At first I had no interfaces selected, but I have then tried all other combinations without success. According to the logs there have been occasions when it worked, but the last several tries it failed every time I manually started it.
Also interesting is that I have 3 pfsense routers:
Box 1 and 2:
Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz 8 CPUs: 1 package(s) x 4 core(s) x 2 SMT threads
These are the ones I'm bringing up now for the first time, and started with v2.1
Box 3:
Intel(R) Xeon(R) CPU E31220L @ 2.20GHz 4 CPUs: 1 package(s) x 2 core(s) x 2 SMT threads
This has been in heavy use for quite some time now. I think from circa v2.0.0, each time upgrading to the stable releases.Otherwise the HW is the same on all three (same motherboard, chassis, PS,…). Box 1 and 2 are failing NTPD as mentioned above nearly instantly, and very constantly. Box has had NTP up and running solidly for "21 Days 05 Hours 32 Minutes 10 Seconds" i.e. since it was upgraded to 2.1 and rebooted a couple times in the process. The point is could the problem be related to the CPU type? (I sure hope not). Could the problem be related to NOT having upgraded from 2.0.3 to 2.1 as compared to installing 2.1 directly?
Also in case its important I'm running 64-bit Nano from a small USB flash drive (on all three).
If there is anything I can do to help let me know what.
-Miki
-
The method for selecting every interface changed between 2.0.x and 2.1, highlighting every interface or defaulting to all.
Do you have ntpd listening on all interfaces on each box? Compare the ntpd section of the config files.Steve
-
I'm selecting none of the interfaces on the GUI, which is supposed to listen on all interfaces. I've confirmed that by cat-ing /var/etc/ntpd.conf:
# # pfSense ntp configuration file # tinker panic 0 # Upstream Servers server 0.pfsense.pool.ntp.org iburst maxpoll 9 enable monitor enable stats statistics clockstats statsdir /var/log/ntp logconfig =syncall +clockall driftfile /var/db/ntpd.drift restrict default kod nomodify notrap nopeer restrict -6 default kod nomodify notrap nopeerI've compared the file to the working one, and there are no unexpected differences. The interfaces on the working one are explicitly specified in the ntpd.conf as em0 and em0_vlan14 (a.k.a. OPT1). I tried the same on the non-working ones ( other than OPT1 since those don't have an OPT1), and no luck.
I did notice that when I start ntpd by hand from the shell it works just fine. The web GUI was showing some peers, and stats. I haven't let it continue for more than an hour or so like that, but no issues. I then stopped it in the shell, and then started it in the gui, and it still doesn't start from the GUI.
-
My previous post is a bit ambiguous, maybe even wrong. When running it by hand I meant running ntpd as-is with no arguments. That, as I now found out on the working box, is not how it's run from the GUI.
so then I ran
/usr/local/bin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pidwhich is how it's run from the GUI, and sure enough it did crash. So then next step I wanted it to not fork, so I can maybe catch more output. I ran it like this```
/usr/local/bin/ntpd -n -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pidI'm not sure what to make of this. Is there anyway I can help the devs in figuring this one out. I'm a dev myself. Thanks, Miki -
hi
I have the same problem with ntp
kernel: pid 71748 (ntpd), uid 0: exited on signal 11 (core dumped)
I upgraded from 2.0.3 to 2.1 (amd64) on physical machine with Xeon X3430 @ 2.40GHz 4GB
The only solution on my system is go to System > Generel Setup > Click on 'Save' After this the NTPd starts automatically and peers are present under Status > NTP
My System log: (this happens every morning after periodic reset)
Jan 21 01:00:18 kernel: pid 25498 (ntpd), uid 0: exited on signal 11 (core dumped)
Jan 21 01:00:16 check_reload_status: Reloading filter
Jan 21 01:00:16 check_reload_status: Starting packages
Jan 21 01:00:16 php: rc.newwanip: pfSense package system has detected an ip change x.x.x.179 -> x.x.x.179 … Restarting packages.
Jan 21 01:00:14 php: rc.newwanip: Creating rrd update script
Jan 21 01:00:14 php: rc.newwanip: Resyncing OpenVPN instances for interface WAN1.
Jan 21 01:00:09 php: rc.newwanip: Removing static route for monitor 8.8.4.4 and adding a new route through x.x.x.x
Jan 21 01:00:09 php: rc.newwanip: Removing static route for monitor 8.8.8.8 and adding a new route through x.x.x.x
