On Debian Wheezy, running on a 2+ GHz 4 core Xeon, 'nsdc restart' just stopped nsd3. Adding a 'sleep 1' after the 'done' in nsdc's controlled_stop got it to stop and start.
On a Raspberry Pi (with its built in sleep 1), it was fine...
We have been experiencing this too on every nsdc restart since our
upgrades to wheezy/nsd 3.2.5:
Apr 18 22:49:28 os4 nsd[26962]: can't bind udp socket: Address already in use
Apr 18 22:49:28 os4 nsd[26962]: server initialization failed, nsd
could not be started
It doesn't help that "nsdc running" has also been broken and no longer
correctly detects whether nsd is running (always returns 0 due to the
"return 1" being removed from the function "signal"), so the scripts
we've been using to
prevent this exact situation have also been failing to detect it exiting.
David
Hi,
We have been experiencing this too on every nsdc restart since our
upgrades to wheezy/nsd 3.2.5:Apr 18 22:49:28 os4 nsd[26962]: can't bind udp socket: Address
already in use Apr 18 22:49:28 os4 nsd[26962]: server initialization
failed, nsd could not be startedIt doesn't help that "nsdc running" has also been broken and no
longer correctly detects whether nsd is running (always returns 0 due
to the "return 1" being removed from the function "signal"), so the
scripts we've been using to prevent this exact situation have also
been failing to detect it exiting.
To my knowledge, the signal function has not been changed since 3.2.0,
that 'return 1' is still in the code.
David
On Debian Wheezy, running on a 2+ GHz 4 core Xeon, 'nsdc restart'
just stopped nsd3. Adding a 'sleep 1' after the 'done' in nsdc's
controlled_stop got it to stop and start.On a Raspberry Pi (with its built in sleep 1), it was fine...
controlled_sleep should avoid just that. Adding a 'sleep 1' might work,
but it feels to me not like a genuine solution.
Best regards,
Matthijs
Thanks, I found a Debian-specific patch that is breaking this
behaviour and have submitted a bug report there.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745506
David
Absolutely not. But hacking a shell script is much quicker than filing a bug report and waiting for a knowledgeable developer to figure out what's going on and change the nsd source. But I did get it to work (here, at least), and hopefully pointed a developer at a flaw that shows up on newer hardware, maybe to be dealt with in the next release.
Like the subject says: trivia...