Upgrade to 2.1 ntpd service have to manually start each time now.
-
I have manually start this now any ideas? it stays running once started.
It might otherwise be going down because of this I am not sure. On boot it starts in console, but on dashboard it shows not started.
ntpd exiting on signal 15
Is this a known bug? As i have read this thread.
-
Just did a fresh install and worked fine until I added squid same result have to manually start ntpd.
Why is it after every upgrade stupid little problems always occur? It never seems to upgrade perfectly with pfsense.
-
Are you also running virtualised? NTPd can have a hard time in a VM because the virtual clock provided does not always behave like a real one.
Do you have a number of interfaces selected? There was a slight change in behaviour between 2.0.X and 2.1 as I recall. I think that previously selecting no interfaces did nothing but now that defaults to all interfaces. :-\ (could be the other way around) Perhaps you have managed to select no interfaces so it's just quitting?
Steve
-
I have manually start this now any ideas? it stays running once started.
It might otherwise be going down because of this I am not sure. On boot it starts in console, but on dashboard it shows not started.
ntpd exiting on signal 15
Is this a known bug? As i have read this thread.
Give it a few minutes and it should auto-start. I was seeing the same problem until I realized it takes a couple minutes for the local NTP to converge and the ntpd server to start.
-
Thanks both of you for your input.
I am running virtualised. I tried selecting the interface relevant, Still the same also gave it some time around 10 minutes doesn't start.
-
I've seen this issue with NTP dying before, usually when running in ESXi or VirtualBox or something and usually 64 bit version.
http://forum.pfsense.org/index.php/topic,66616.30.html (Went round and round before stumbling into answer)
The easy cure before was to install the 32 bit version of pfsense and problems went away.
If you are allocating 4GB RAM or less this might be something you should try.
-
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
