Bug 711 - error: can't bind udp socket: Address already in use
error: can't bind udp socket: Address already in use
Product: NSD
Classification: Unclassified
Component: NSD Code
x86_64 Linux
: P5 normal
Assigned To: NSD team
Depends on:
  Show dependency treegraph
Reported: 2015-10-12 13:17 CEST by Balint Szigeti
Modified: 2015-10-12 14:57 CEST (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Balint Szigeti 2015-10-12 13:17:02 CEST

NSD can't start if multiple interface(ip-address) are specified and debug-mode is not enabled. 

I use nsd-4.1.5 version and daemontools as supervisor. The supervisor starts
nsd as:
exec /usr/sbin/nsd -c /etc/nsd/nsd.conf -P /var/run/nsd/nsd.pid

this is the non-working configuration:
        hide-version: yes
#       debug-mode: yes
        verbosity: 2
        ip4-only: yes
        #ip-transparent: yes
        reuseport: yes
        database: "/var/lib/nsd/nsd.db"
        identity: "none"
        round-robin: yes
        # nsid: "hy-mdsdinfr02c"
        logfile: "/var/log/nsd.log"
        server-count: 1
        tcp-count: 10
        tcp-query-count: 0
        tcp-timeout: 120
        ipv4-edns-size: 4096
        pidfile: "/var/run/nsd/nsd.pid"
        port: 53
        # statistics: 3600
        # zone-stats-file: "/var/log/nsd.stats"
        # chroot: "/etc/nsd"
        username: nsd
        zonesdir: "/etc/nsd/zones"
        # Ignored, for compatibility with NSD3 config files.
        # difffile: "/var/lib/nsd/ixfr.db"
        xfrdfile: "/var/lib/nsd/ixfr.state"
        xfrdir: "/var/lib/nsd"
        xfrd-reload-timeout: 10
        # rrl-size: 1000000
        # rrl-ratelimit: 200
        # rrl-slip: 2
        # rrl-ipv4-prefix-length: 24
include: "/etc/nsd/zones.conf"
Comment 1 Wouter Wijngaards 2015-10-12 13:46:05 CEST
Hi Balint,

Debug mode should not really matter for interface binding?  However, you can only start one server, eg. on port 53.  Sometimes also other servers (a recursor like Unbound) is set to service  netstat may be able to tell you what processes are listening to port 53.  

Perhaps you reference to debug mode means you experimented on the commandline and a process forked into the background still holding port 53?

That said, this configuration would work, I think, if it does not there is some bug; but first look for other processes on port 53.

Your server-count is 1.  If you have it higher, then reuseport: no in nsd.conf will turn off a new feature in NSD 4.1.5 that sets a new socket option that affects the interface binding.

Best regards, Wouter
Comment 2 Balint Szigeti 2015-10-12 14:03:43 CEST
just NSD listens on localhost 53 port. see the netstat output.

tcp        0      0     *                   LISTEN      24209/nsd
tcp        0      0      *                   LISTEN      24209/nsd
udp        0      0     *                               24209/nsd
udp        0      0      *                               24209/nsd

tcp        0      0     *                   LISTEN      20286/unbound
tcp        0      0      *                   LISTEN      20286/unbound
udp        0      0     *                               20286/unbound
udp        0      0      *                               20286/unbound

well, if I increase server-count higher with the existing config, the system will collapses. The load goes to the sky :(
Comment 3 Wouter Wijngaards 2015-10-12 14:08:28 CEST
Hi Balint,

Yes it looks fine with port 55 for Unbound.

So NSD did start and you can see it running?  How did you start it?  With debug-mode?  But that only changes one fork() call, in essence?

Multiple server-count should not actually increase server-load (but it does use a lot of virtual memory, perhaps?).  But that is an optimisation.

So, the bug happens with this configuration but goes away when you enable debug-mode?  And then you get the netstat you show?

Best regards, Wouter
Comment 4 Balint Szigeti 2015-10-12 14:36:13 CEST
So NSD did start and you can see it running?

How did you start it?
as I wrote before with daemontools supervisor. The start script is:
exec /usr/sbin/nsd -c /etc/nsd/nsd.conf -P /var/run/nsd/nsd.pid

With debug-mode?  
yes. without debug-mode the NSD can't start with the bug's subject message

But that only changes one fork() call, in essence?
sorry, I don't know what you mean. 

So, the bug happens with this configuration but goes away when you enable debug-mode? 

And then you get the netstat you show?
Comment 5 Wouter Wijngaards 2015-10-12 14:41:05 CEST
Hi Balint,

Of course, deamontools; the supervisor restarts the server when it detaches from the controlling console.  This is to restart the server when it crashes (it then disappears from the controlling console).  When debug-mode is no NSD forks into the background and detaches from the console.  Then the supervisor restarts it, but actually the original NSD is still running (holding port 53).  And then you get the error.

So, you have to enable the option called debug-mode: yes, because this enables functionality in NSD4 to stay attached to the controlling console, so that the daemontools supervisor can monitor it.  It used to be called debug-mode because it is also used from the commandline console.  But it is also useful with (these kinds of) supervisors.

So, this is not a bug.  Set debug-mode: yes in the config file and add a comment that this stops it from detaching from the console so that the supervisor can monitor the server health.

(your original message contained enough information, but I failed to realize that this was the problem).  Does that solve your problem(s)?

Best regards, Wouter
Comment 6 Balint Szigeti 2015-10-12 14:53:35 CEST
yes, that was my issue. thank you, it is resolved now
it could be written in the man pages a slightly clearer?
in the 'man nsd' the -d option mention it but it wasn't obvious about the debug-mode.
Comment 7 Wouter Wijngaards 2015-10-12 14:57:25 CEST
Hi Balint,

Yes, I'll update the man pages.  With this text

+If set to yes it does not fork and stays in the foreground, which can
+be helpful for commandline debugging, but is also used by certain
+server supervisor processes to ascertain that the server is running.

Best regards, Wouter