Bugzilla – Bug 17571
SBS loses connection to MySB whenever the internet connection is temporarily lost
Last modified: 2014-03-11 15:24:53 UTC
I'm seeing this on my Mac with all versions of SBS I've tried since 7.5.x OSX is 10.6.8 but it has been the same with previous versions of 10.6 I've got a spotty ISP and also often use a MyFi router so my Mac disconnects from the internet from time to time. After it does so, SBS permanently loses the connection to MySB (and logs errora like that it can not download player information). All MySB "Apps" are no longer available then. I have to restart the server to make SBS reconnect to MySB.
Andy - that's something I've seen reported a lot, in particular for NAS users: in those cases it can happen that SBS is started before the network is fully started, or the DNS proxy or whatever. Anyway: if a name resolution request for mysb.com fails, SBS would never try to find it again, but would just continue to fail to provide mysb.com based services. Pippin's case is different in the issue cause this behaviour, but the SBS not trying again issue is most likely the same.
*** Bug 17917 has been marked as a duplicate of this bug. ***
I would like to vote to get this looked at but cannot make the site work. I have been unable to use my SB Server to get to internet radio stations for some time and restarting the server doesn't fix it. Server returns the DNS errors.
To echo marsi I am having the same issue. Restarting the Server does not resolve the issue. I can get to mySB.com via a web browser, and if I open the "Diagnostics" tab in LMS Control Panel under mysqueezebox.com, the server IP Address resolves to 50.17.234.107, and the ping and port info reports ok. I not only can't use internet radio, but I can't connect to the License server app which is preventing me from being able to use 3rd party apps that I have paid for.
I cannot reproduce this. Please try to get a log with network.asyncdns if you think it is DNS-related. I was able to start LMS, shut down wifi on my Mac, get a few lookup failures, restart Wifi, and things were fine again as expected. [12-03-12 15:30:47.0070] Slim::Networking::Async::DNS::__ANON__ (105) Got DNS response 50.17.238.167 for www.mysqueezebox.com (ttl 48) [12-03-12 15:35:59.0033] Slim::Networking::Async::DNS::__ANON__ (96) Lookup failed for www.mysqueezebox.com [12-03-12 15:35:59.0070] Slim::Networking::SqueezeNetwork::Players::_players_error (334) Unable to get players from SN: Couldn't resolve IP address for: www.mysqueezebox.com, retrying in 300 seconds [12-03-12 15:36:05.0046] Slim::Networking::Async::DNS::__ANON__ (96) Lookup failed for www.mysqueezebox.com [12-03-12 15:36:05.0053] Slim::Networking::SqueezeNetwork::Players::_players_error (334) Unable to get players from SN: Couldn't resolve IP address for: www.mysqueezebox.com, retrying in 600 seconds [12-03-12 15:36:22.8400] Slim::Networking::Async::DNS::__ANON__ (105) Got DNS response 50.17.238.167 for www.mysqueezebox.com (ttl 17) [12-03-12 15:36:22.8414] Slim::Networking::Async::DNS::__ANON__ (105) Got DNS response 50.17.238.167 for www.mysqueezebox.com (ttl 17) [12-03-12 15:36:22.9984] Slim::Networking::Async::DNS::resolve (81) Using cached DNS response 50.17.238.167 for www.mysqueezebox.com [12-03-12 15:36:23.0004] Slim::Networking::Async::DNS::resolve (81) Using cached DNS response 50.17.238.167 for www.mysqueezebox.com [12-03-12 15:36:35.8571] Slim::Networking::Async::DNS::resolve (81) Using cached DNS response 50.17.238.167 for www.mysqueezebox.com
Andy - what if you _started_ LMS while the DNS was down or unreachable, or with a mis-configured hosts file to make lookup for mysb.com fail, then you restore things? LMS would not recover. I think this use-case is not that un-common: on some systems LMS might be started before the network is fully set up or functioning. I've seen reports for this for Windows as well as Linux & BSD systems.
*** Bug 14199 has been marked as a duplicate of this bug. ***
Seem sthis bug missed the 7.7.2 release after all... Is there a way of diabling the DNS caching?
*** Bug 15789 has been marked as a duplicate of this bug. ***
*** Bug 17701 has been marked as a duplicate of this bug. ***
*** Bug 17993 has been marked as a duplicate of this bug. ***
I think my comment #6 was spot on - but it took me... ahm... two years to finally track it down: when the first DNS lookup is done, LMS (or the underlying module being used) would read the system configuration to figure out how to resolve file names. If that configuration happened to be invalid or not ready yet, LMS would just continue to use it, failing any subsequent lookup. This should be fixed in both 7.7 and 7.8. Please give one of the next nightlies another try! Please note that picking up changes can still take a few minutes. But you should no longer require a LMS restart to overcome the "couldn't resolve IP address for..." issue.