Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    OpenNTP will not start

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    20 Posts 6 Posters 12.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • AhnHELA
      AhnHEL
      last edited by

      Executing the command line I get the following after making the edit:

      root(1): /usr/local/sbin/ntpd -d -f /var/etc/ntpd.conf
      listening on 192.168.1.1
      fatal: bind: Address already in use
      dispatch_imsg in main: pipe closed
      Terminating
      

      Without making any edits, I get output and the service is running but mind you I dont have the listen on entries in the conf file so no clients can sync to ntpd.

      /usr/local/sbin/ntpd -d -f /var/etc/ntpd.conf
      ntp engine ready
      reply from 209.167.68.100: offset 0.076802 delay 0.020013, next query 8s
      reply from 173.193.227.67: offset 0.080000 delay 0.019019, next query 9s
      reply from 72.26.125.125: offset 0.081708 delay 0.085034, next query 8s
      reply from 209.167.68.100: offset 0.078196 delay 0.018326, next query 8s
      reply from 72.26.125.125: offset 0.082557 delay 0.084236, next query 7s
      reply from 173.193.227.67: offset 0.080637 delay 0.014315, next query 7s
      reply from 72.26.125.125: offset 0.081665 delay 0.080064, next query 9s
      reply from 209.167.68.100: offset 0.078240 delay 0.018210, next query 6s
      reply from 173.193.227.67: offset 0.082350 delay 0.018398, next query 6s
      peer 209.167.68.100 now valid
      reply from 209.167.68.100: offset 0.079528 delay 0.019125, next query 8s
      peer 173.193.227.67 now valid
      reply from 173.193.227.67: offset 0.083322 delay 0.019781, next query 6s
      peer 72.26.125.125 now valid
      reply from 72.26.125.125: offset 0.082294 delay 0.079365, next query 9s
      reply from 173.193.227.67: offset 0.083190 delay 0.016300, next query 6s
      reply from 209.167.68.100: offset 0.080482 delay 0.019987, next query 8s
      /etc/inc/system.increply from 72.26.125.125: offset 0.083860 delay 0.081156, next query 9s
      reply from 173.193.227.67: offset 0.083825 delay 0.015223, next query 8s
      reply from 209.167.68.100: offset 0.081236 delay 0.019048, next query 8s
      ^Cntp engine exiting
      Terminating
      
      

      So it seems my only issue is getting the string(s) that put the listen on entries into the conf file because the service is running fine.

      AhnHEL (Angel)

      1 Reply Last reply Reply Quote 0
      • S
        skywalker
        last edited by

        has someone managed to fix this?
        I ran into exactly the same problem.
        I noticed that after fixing the system.inc, the /usr/local/sbin/ntpdate_sync_once.sh script seems to run forever thus blocking port 123 thus ntpd won't start.
        Does this help?

        1 Reply Last reply Reply Quote 0
        • R
          racmar
          last edited by

          Yes, I have this same problem with ntpdate_sync_once.sh running forever.  My temp. fix is to comment out ntpdate on line 7 like so:

          	#ntpdate $SERVER
          
          

          I haven't figured out why it is hanging and blocking port 123, but the above temp. fix at least lets ntpd run.

          1 Reply Last reply Reply Quote 0
          • T
            Tikimotel
            last edited by

            I'm puzzled by the message from Onhel:
            root(1): /usr/local/sbin/ntpd -d -f /var/etc/ntpd.conf
            listening on 192.168.1.1
            fatal: bind: Address already in use
            dispatch_imsg in main: pipe closed
            Terminating

            Have you tried "loopback" (a.k.a 127.0.0.1) is it also already in use?

            I only needed to make my above mentioned adjustments and open the firewall (locally) for the ntp port, in order to get clients to use pfsense as a ntp-server.

            Onhel ? Clean install or Update over pfsense 1.2.3 ?
            Maybe some older 1.2.3 firewall settings mess thing up. (old default rules?)

            My system is a clean pfsense 2.0 install from late march and updated via manual update. (2.0-RC1 (amd64) built on Fri Mar 25 03:25:35 EDT 2011 )
            (stopped updating for a while now, since the upnp problems of recent snapshots.)

            I had to add the LAN firewall settings myself. No default "rules" for reaching dns forwarder, upnp or nat-pmp for instance.
            (this works for me… )

            Firewall_settings_NTP.png
            Firewall_settings_NTP.png_thumb

            1 Reply Last reply Reply Quote 0
            • AhnHELA
              AhnHEL
              last edited by

              Yes Loopback is on.

              Its from a clean install, started from scratch some time ago so no remnants of 1.2.3

              I even used a clean install and removed all references to ntpd in my config.  Only way to get it running is to kill all ntp processes and then I can start and stop the service as normal but I still get fatal bind error running the above command.

              AhnHEL (Angel)

              1 Reply Last reply Reply Quote 0
              • V
                vorgusa
                last edited by

                I am having the same problem still with "built on Wed Apr 6 "  its the script used to update the time when the pfsense starts (at least thats what I think it does)

                [2.0-RC1][user@router]/home/user(5): ps -aux | grep ntp
                root     38597  0.0  0.1  3656  1400  ??  SN    7:47PM   0:05.38 /bin/sh /usr/local/sbin/ntpdate_sync_once.sh
                root     38697  0.0  0.1  3656  1364  ??  IN    7:47PM   0:00.00 /bin/sh /usr/local/sbin/ntpdate_sync_once.sh
                root     41630  0.0  0.1  3504  1356  ??  SN    7:47PM   0:00.25 ntpdate 0.pfsense.pool.ntp.org
                root     12536  0.0  0.1  3656  1396  v0- S     7:47PM   0:05.34 /bin/sh /usr/local/sbin/ntpdate_sync_once.sh

                It just hangs and leaves the port open so when NTPD tries to start it can not.  Once those are killed ntpd can start.

                The script seems to run fine once the original ones have been killed, maybe something to do with when/how its started?

                [2.0-RC1][root@router]/usr/local/sbin(7): ./ntpdate_sync_once.sh
                7 Apr 08:28:57 ntpdate[41586]: adjust time server 207.150.168.70 offset 0.032785 sec
                [2.0-RC1][root@router]/usr/local/sbin(9): ps -aux | grep ntp
                root    42402  0.0  0.1  3316  1340  ??  Ss    8:29AM  0:00.00 ntpd: [priv] (ntpd)
                _ntp    42196  0.0  0.1  3316  1344  1  S    8:29AM  0:00.00 ntpd: ntp engine (ntpd)

                1 Reply Last reply Reply Quote 0
                • V
                  vorgusa
                  last edited by

                  Do the people with the problem have a VPN running? if I stop my NTPD and restart my site to site vpn, I get the ntpdate_sync_once script again plus ntpdate.  NTPD does not start up which I believe the ntpdate_synch script is supposed to do when its done

                  [2.0-RC1][root@router]/etc(48): ps -aux | grep ntp
                  root    22882  1.1  0.1  3504  1396  ??  SN    9:00AM  0:00.01 ntpdate 0.pfsense.pool.ntp.org
                  root    21483  1.0  0.1  3656  1504  ??  SN    9:00AM  0:00.00 /bin/sh /usr/local/sbin/ntpdate_sync_once.sh

                  1 Reply Last reply Reply Quote 0
                  • R
                    racmar
                    last edited by

                    Now that I think about it, the NTPD problem did start after I enabled the VPN.

                    1 Reply Last reply Reply Quote 0
                    • R
                      racmar
                      last edited by

                      I just deleted my VPN and NTPD start fine after a reboot.  Interesting, and good catch vorgusa!

                      1 Reply Last reply Reply Quote 0
                      • AhnHELA
                        AhnHEL
                        last edited by

                        Some commits but still not running right, see below link.

                        http://redmine.pfsense.org/issues/1397

                        AhnHEL (Angel)

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.