• In GUI, if I go to Services/OpenNTPD, and enable the checkbox, then the Services/Status shows ntpd as Stopped.

    If I disable NTP server by unchecking the box, then the Services/Status shows ntpd as Running.

    Its completely reversed and either way running or stopped it doesnt seem to be working properly.

    I'm seeing this on snaps after March 4th using amd64,  if I go back to March 2nd, it works the way it should.

  • I am using:
    2.0-RC1 (i386) built on Wed Mar 2 03:30:11 EST 2011

    If I enable OpenNTPD on LAN interface, this line comes up in Systemlog "system".

    php: /pkg_edit.php: The command '/usr/bin/killall 'ntpd'' returned exit code '1', the output was 'killall: warning: kill -TERM 4781: No such process'

    If I disable OpenNTPD on LAN interface, this line comes up in Systemlog "system".

    php: /pkg_edit.php: The command '/usr/bin/killall 'ntpd'' returned exit code '1', the output was 'killall: warning: kill -TERM 7464: No such process'

  • I have the same results. Disabling NTPD under Services shows it being started under Status:Services. I don't see anything in my system log tho. Running 2.0-RC1 (i386) built on Sun Mar 6 03:05:44 EST 2011

  • I'm hoping this is just another side effect of the yandex em driver that was committed recently

  • Rebel Alliance Developer Netgate

    Not likely. It happens on my ALIX as well and this isn't anywhere near the network drivers.

  • If I go in an kill all the ntpdate processes and then go and re-enable ntp .. the service shows as started.


  • Is anyone else still having problems with this?  It's showing still reversed on my full i386 machine.

  • This was fixed in the most recent snapshots.  Please note that saving a OpenVPN config though will shut it down and will not allow it to start back up again until a reboot is performed, or you kill all ntp processes and restart ntpd

  • Just updated to 2.0-RC1 (i386) built on Mon Apr 11 15:52:08 EDT 2011 and it is still showing the status reversed.  When it is running it shows stopped, when I stop it, it shows running.

  • Rebel Alliance Developer Netgate

    It should show running all the time. It being enabled/disabled only changes whether it listens for client access. When you have the enable box unticked, it is still used to keep the clock in sync.

    On my test VMs, it shows enabled all the time now on current snapshots.

    Anyone who still sees it show on/off incorrectly, I need to see the output of "ps uxawww | grep ntp"

  • root   12897  0.0  0.2  3656   872  ??  IN   10:32PM   0:00.02 /bin/sh /usr/local/sbin/ntpdate_sync_once.sh
    root   17460  0.0  0.2  3504  1084  ??  IN   10:32PM   0:00.24 ntpdate -s -t 5 0.pfsense.pool.ntp.org
    root   22432  0.0  0.2  3524   996  u0  S+   11:31AM   0:00.01 grep ntp
  • Rebel Alliance Developer Netgate

    How far off from the current clock is that 10:32? It's odd that ntpdate would be stuck there but I ahve seen it do that before. It's supposed to stop itself after 5 seconds, but sometimes doesn't.

    Anything in the system log from ntpdate?

    I'm going to be replacing ntpdate with just running ntpd with -s instead. Might clear everything up but will take a little work to pull off.

  • Jimp, I've been seeing the same (not running / inverted status).

    The output of "ps uxawww | grep ntp" on my machine is:

    $ ps uxawww | grep ntp
    root    48849  0.0  0.6  3656  1416  ??  S     6:55PM   0:00.00 sh -c ps uxawww | grep ntp
    root    49007  0.0  0.5  3524  1252  ??  S     6:55PM   0:00.00 grep ntp
    root    54158  0.0  0.6  3656  1364  ??  IN   10:34AM   0:00.01 /bin/sh /usr/local/sbin/ntpdate_sync_once.sh
    root    56211  0.0  0.6  3504  1356  ??  SN   10:34AM   0:00.20 ntpdate 1.nl.pool.ntp.org 0.nl.pool.ntp.org 0.pfsense.pool.ntp.org0
    root    25863  0.0  0.6  3656  1404  u0- S    10:34AM   0:05.94 /bin/sh /usr/local/sbin/ntpdate_sync_once.sh

    As for the time 10:34AM, it's 19:00 (7PM) right now.

  • the 10:32PM is way off, the 11:31A is pretty much exact.

  • Rebel Alliance Developer Netgate

    ok, so it's been stuck for quite a while.

  • yeah, been stuck since i updated the firewall last night. whats weird is if I uncheck the box, it shows running under services and gives me this as an output for that command

    root   55531  1.0  0.2  3316  1052  ??  Ss   12:14PM   0:00.00 ntpd: [priv] (ntpd)
    root   12897  0.0  0.2  3656   808  ??  IN   10:32PM   0:00.02 /bin/sh /usr/local/sbin/ntpdate_sync_once.sh
    root   17460  0.0  0.2  3504   828  ??  IN   10:32PM   0:00.26 ntpdate -s -t 5 0.pfsense.pool.ntp.org
    _ntp   55364  0.0  0.2  3316  1060  ??  S    12:14PM   0:00.01 ntpd: ntp engine (ntpd)
    root   34601  0.0  0.1  1848   536  u0  R+   12:15PM   0:00.00 grep ntp

    the 12:15 is dead on!

  • Rebel Alliance Developer Netgate

    Yes, when ntpdate_sync_once.sh runs it kills ntpd, syncs the time, and then restarts ntpd. If it gets stuck in the sync part, then it never restarts ntpd.

    This is going to change here shortly, though. Don't bother investigating any more just yet.

  • Sweet, thanks pfSense team.

  • Rebel Alliance Developer Netgate

    Try to apply this change (or wait for a new snap dated after this post):


  • Reboot after making changes?

  • Rebel Alliance Developer Netgate

    That would be an ideal test, yes. At least kill all ntp and ntpdate processes and then edit/save the OpenNTPD settings.

    Though a reboot would be the most accurate test.

  • Showing running on the services menu after making changes and rebooting.

    Output of: "ps uxawww | grep ntp"

    _ntp   53655  0.0  0.2  3316  1256  ??  S     2:50PM   0:00.01 ntpd: ntp engine (ntpd)
    root   53981  0.0  0.3  3316  1280  ??  Ss    2:50PM   0:00.00 ntpd: [priv] (ntpd)
    root   10769  0.0  0.2  3524  1096  u0  S+    2:52PM   0:00.01 grep ntp

  • After updating to the latest snap, all is green on my machine.
    Thanks a lot jimp!

  • Rebel Alliance Developer Netgate

    Should be good then, ntpd should always be running now, no ntpdate at all anymore.

  • Yes!  Finally my network feels like Utopia again, many thanks JimP.