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

    UNBOUND error: bind: address already in use fatal error: could not open ports

    Scheduled Pinned Locked Moved DHCP and DNS
    12 Posts 6 Posters 10.7k 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.
    • M
      Mr. Jingles
      last edited by

      G'evening,

      I googled it, but it seems it's a 2011/2012 problem (?)

      
      Jan 29 18:10:00  php-cgi  servicewatchdog_cron.php: Service Watchdog detected service unbound stopped. Restarting unbound (Unbound DNS Resolver)        
      Jan 29 18:09:40  php-fpm /services_dhcp.php: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '[1485709780] unbound[38648:0] error: bind: address already in use [1485709780] unbound[38648:0] fatal error: could not open ports' 
      

      I'm on 2.3.2-p1.

      I already rebooted, didn't solve it.

      6 and a half billion people know that they are stupid, agressive, lower life forms.

      1 Reply Last reply Reply Quote 0
      • D
        doktornotor Banned
        last edited by

        Hint: Do NOT ever add Unbound to Service Watchdog. Especially not if using pfBlockerNG.

        1 Reply Last reply Reply Quote 0
        • M
          Mr. Jingles
          last edited by

          Good to see you're back, Dok ;D

          Ok, I'll remove it from serwadog. Strange, that a wadog would cause this, but what the bleep do I know  :P

          6 and a half billion people know that they are stupid, agressive, lower life forms.

          1 Reply Last reply Reply Quote 0
          • D
            doktornotor Banned
            last edited by

            When Unbound restarts on its own (DHCP registration, pfBNG…), the watchdog cronjob often spots this and tries to restart it on its own as well. Trying to start it twice at the same time will fail. Really no good.

            1 Reply Last reply Reply Quote 0
            • M
              Mr. Jingles
              last edited by

              You were right, Dok, thank you. Removing it = no unbound crashes in 24 hours.

              6 and a half billion people know that they are stupid, agressive, lower life forms.

              1 Reply Last reply Reply Quote 0
              • luckman212L
                luckman212 LAYER 8
                last edited by

                I'm on 2.4 snapshots (2.4.0.b.20170209.0450 to be exact) and I am NOT using Service Watchdog.  Don't even have it installed.

                I'm getting this error too from rc.newwanip about not being able to start Unbound. It happens after WAN flaps.  There's some kind of deadlock or race condition going on. If I just wait a few seconds, and then manually start the service from the dash it comes up. Strange timing issue.  But Unbound is such a critical part of the system, it really does need a watchdog.

                1 Reply Last reply Reply Quote 0
                • P
                  pfcode
                  last edited by

                  @luckman212:

                  I'm on 2.4 snapshots (2.4.0.b.20170209.0450 to be exact) and I am NOT using Service Watchdog.  Don't even have it installed.

                  I'm getting this error too from rc.newwanip about not being able to start Unbound. It happens after WAN flaps.  There's some kind of deadlock or race condition going on. If I just wait a few seconds, and then manually start the service from the dash it comes up. Strange timing issue.  But Unbound is such a critical part of the system, it really does need a watchdog.

                  if you have pfBlockerNG DNSBL enabled, then disabling it will fix.

                  Release: pfSense 2.4.3(amd64)
                  M/B: Supermicro A1SRi-2558F
                  HDD: Intel X25-M 160G
                  RAM: 2x8Gb Kingston ECC ValueRAM
                  AP: Netgear R7000 (XWRT), Unifi AC Pro

                  1 Reply Last reply Reply Quote 0
                  • luckman212L
                    luckman212 LAYER 8
                    last edited by

                    @pfcode:

                    if you have pfBlockerNG DNSBL enabled, then disabling it will fix.

                    But, I don't have pfBNG installed.

                    1 Reply Last reply Reply Quote 0
                    • S
                      SteveITS Galactic Empire
                      last edited by

                      luckman212, did you ever find a fix for this issue of unbound not restarting successfully?  We've been running into the same thing on a HA pair where both are acting as DNS servers.  When the daily Suricata rules update and hence sync happens, the packages are restarted on the backup router and it logs:

                      /xmlrpc.php: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '[1493810636] unbound[78923:0] error: bind: address already in use [1493810636] unbound[78923:0] fatal error: could not open ports'

                      I think this is relatively new (we have 2.3.3_1 currently) but I'm not quite sure when it started.  I know it occurred at least once before installing pfBlockerNG, and disabling pfBlockerNG on both routers or even uninstalling pfBlockerNG had no effect.

                      The weird part is I can go to the Suricata sync or the HA sync page and save, which seems to trigger a sync, without issue.  And rule updates that sync don't cause this issue.

                      Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
                      When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
                      Upvote 👍 helpful posts!

                      1 Reply Last reply Reply Quote 0
                      • BBcan177B
                        BBcan177 Moderator
                        last edited by

                        Try the following patch:
                        https://redmine.pfsense.org/issues/7326#note-2

                        "Experience is something you don't get until just after you need it."

                        Website: http://pfBlockerNG.com
                        Twitter: @BBcan177  #pfBlockerNG
                        Reddit: https://www.reddit.com/r/pfBlockerNG/new/

                        1 Reply Last reply Reply Quote 0
                        • S
                          SteveITS Galactic Empire
                          last edited by

                          Thanks for the pointer.  I forgot this forum doesn't automatically subscribe you to threads when you reply, so it took a day to remember to check for a reply.

                          I had found that bug report also but was hesitant to start modifying code.  I did so and overnight our backup router logged 18 "waiting 1 second" messages over a 24 second span, but successfully started unbound.  It seems weird that this only affects our backup router (I didn't even put the fix into our master), and I'm fairly confident it hasn't been an issue for the entire time we've been using Suricata…since last fall or maybe summer, without looking.

                          It doesn't appear your fix/workaround made it in today's 2.3.4 release.

                          PS - thanks for pfBlockerNG. :)

                          Edit: curiously, every day since then the router's logged only one "waiting 1 second" message logged.  Still, it's apparently 1 second longer than the "kill" assumes.

                          Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
                          When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
                          Upvote 👍 helpful posts!

                          1 Reply Last reply Reply Quote 0
                          • S
                            SteveITS Galactic Empire
                            last edited by

                            For posterity, it looks like the last patch in that redmine bug made it into 2.3.4_1.

                            My last post said our router only logged one "waiting" message but since then I've seen days where it logs a dozen, give or take, so it varies due to something.  I think the 30 second loop should be long enough though.

                            Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
                            When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
                            Upvote 👍 helpful posts!

                            1 Reply Last reply Reply Quote 0
                            • chudakC chudak referenced this topic on
                            • First post
                              Last post
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.