Karl E. Jorgensen wrote:
> I wonder... What exactly does "bind not responding" mean? any command
> that reproduces that would be handy.
>
> As this is happening in relation to suspend/resume, this would imply
> that network interfaces go down and up too. So perhaps bind is failing
> to detect the re-arrival of network interfaces?
>
> The output of a command like "sudo netstat -nlp | grep bind" while
> bind is not responding would be instructive. And then compare/contrast
> with the scenario of a "working" bind...
I think that is a good debugging direction. For reasons I haven't
looked into BIND will bind to specific addresses. There is always
127.0.0.1:53. Plus there will be one for each interface.
Try:
$ netstat -na | awk '$NF=="LISTEN"&&/:53/'
With this example output from a system.
tcp 0 0 192.168.2.34:53 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
tcp6 0 0 :::53684 :::* LISTEN
tcp6 0 0 :::53 :::* LISTEN
It may be that something is dropping the network offline and the
suspend-resume is simply cycling the network off and on again and
restoring the network connection. Maybe the root cause isn't BIND but
rather that the network has gone offline.
$ ip addr show | awk '$1=="inet"'
inet 127.0.0.1/8 scope host lo
inet 192.168.2.34/24 brd 192.168.230.255 scope global br0
I would also want to know what is in /etc/resolv.conf to know if it is
configured for the local nameserver. And also what "hosts" entry is
listed in /etc/nsswitch.conf to see how it is configured.
$ grep nameserver /etc/resolv.conf
nameserver 127.0.0.1
$ grep hosts /etc/nsswitch.conf
hosts: files dns
Lastly this *shouldn't* be related to any DNS lookups but the contents
of /etc/hosts is the "files" part in the above. It is possible that
contents of /etc/hosts might be confusing the issue of thinking bind
isn't working properly. Shouldn't be since it apparently works after
a suspend-resume but mentioning it here for completeness anyway.
Bob
Attachment:
signature.asc
Description: Digital signature