Comment 8 for bug 1314697
Revision history for this message
| Simon Kelley (simon-thekelleys) wrote Re: [Bug 1314697] Re: Upon upgrade, DNS resolution no longer works | #8 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
On 01/05/14 07:45, Colin King wrote:
> I'm seeing this too, strace show it spinning on:
>
> select(8, [0 3 6 7], [], [6], NULL) = 1 (in [0])
> recvmsg(0, 0x7fffdb2aa6d0, 0) = -1 ENOTSOCK (Socket operation on non-socket)
> accept(0, 0, NULL) = -1 ENOTSOCK (Socket operation on non-socket)
> select(8, [0 3 6 7], [], [6], NULL) = 1 (in [0])
> recvmsg(0, 0x7fffdb2aa6d0, 0) = -1 ENOTSOCK (Socket operation on non-socket)
> accept(0, 0, NULL) = -1 ENOTSOCK (Socket operation on non-socket)
>
> So we're getting ENOTSOCK on fd 0, which is /dev/null :
>
It would be really useful to get an strace of dnsmasq from startup to
when it's in this state, since I've no yet been able to reproduce this.
Also the output of lsof | grep dnsmasq
The bug looks superficially like an earlier one which was triggered by
starting dnsmasq without stdout/stdin/stderr (ie fd 0,1,2). Sockets
would be opened which used these fds, and subsequently the "connect std*
to /dev/null" code would trash them. However that doesn't explain why
both the UDP and TCP listening sockets seem to be zero here.
Cheers,
Simon.