failed to lookup address
Closed this issue · 9 comments
Seems like it tries to lookup 'rammb-slider.cira.colostate.edu:443' instead of 'rammb-slider.cira.colostate.edu':
satpaper --version
satpaper 0.5.0
...
Sep 5 09:42:07 Shiva satpaper[309932]: Error: An error occurred in the wallpaper updating loop
Sep 5 09:42:07 Shiva satpaper[309932]: Caused by:
Sep 5 09:42:07 Shiva satpaper[309932]: 0: https://rammb-slider.cira.colostate.edu/data/imagery/2023/09/05/goes-16--- full_disk/geocolor/20230905062020/04/004_003.png: Dns Failed: resolve dns name 'rammb-slider.cira.colostate.edu:443': failed to lookup address information: Try again
Sep 5 09:42:07 Shiva satpaper[309932]: 1: failed to lookup address information: Try again
...
host rammb-slider.cira.colostate.edu
rammb-slider.cira.colostate.edu is an alias for rammb-slider6.cira.colostate.edu.
rammb-slider6.cira.colostate.edu has address 129.82.20.136
Hmm, interesting - no DNS issues on my end, and the code doesn't mention the port. It's all just ureq::get with rustls, so there shouldn't even be platform-specific weirdness going on...
Have you tried an alternate DNS like 8.8.8.8?
You could also try something like echo "129.82.20.136 rammb-slider.cira.colostate.edu" >> /etc/hosts.
I'm already using 8.8.8.8 - the last string 'host rammb-slider.cira.colostate.edu' is manually entered command that resolves the host perfectly. My platform is Ubuntu 22.x
You could also try something like echo "129.82.20.136 rammb-slider.cira.colostate.edu" >> /etc/hosts
This will not work - the code trying to resolve 'rammb-slider.cira.colostate.edu:443' instead of 'rammb-slider.cira.colostate.edu'
This will not work - the code trying to resolve 'rammb-slider.cira.colostate.edu:443' instead of 'rammb-slider.cira.colostate.edu'
Sorry, but upon deeper investigation, this isn't the case. You're chasing a red herring - ureq is adding the port number, but this is intended, as std::net's ToSocketAddr implementation on strings (which does DNS resolution) expects the format <hostname>:<port>.
Additionally, looking at the URL in the error, it's not the first part of the image - it's 004_003.png, which means you were able to download (or at least start downloading) a few dozen image tiles before the error occurred. The issue clearly lies with your network configuration.
I urge you to try the /etc/hosts bandaid - if this is some hard-to-pin-down problem with Ubuntu's DNS lookup, hardcoding the answer should avoid the issue.
App did not managed to download anything - it is failed just at start. Okay, deleting the app
You're completely misunderstanding how it works, but okay, it's your loss.
@yendefrr - I assume you're also having this issue? Try the /etc/hosts fix I mentioned above. Let me know if you have any luck - I'd love to dig deeper and see what sort of wackiness is causing this.
@Colonial-Dev Not OP, but for what it's worth, I also get this on macos. If I add the hosts file entry, I stop getting the dns error (I wonder if the way rust's dns stuff works doesn't cache well, or something else along those lines)
But... After that, it still won't run on macos due to: Too many open files (os error 24)
I fixed the too many open files error by closing the 6 open VSCode projects I had. XD
That said... now I get timeouts on download... and it kills the whole process. I'm happy to post debug logs if that's helpful.
I wonder if the way rust's dns stuff works doesn't cache well, or something else along those lines
I think it's purely an issue with network configuration. Trawling Github for failed to lookup address information: Try again turns up a handful of issues from other projects, but they all seem to end in "not our fault, something's borked on your end."
But... After that, it still won't run on macos due to:
Too many open files (os error 24)
This I can pretty confidently diagnose. When scraping, Satpaper spawns up to 256 threads (the exact number depends on which satellite) - one thread for each tile of the image.
That's (at minimum) 256 sockets/file descriptors being opened - I guess that plus your VSCode projects were too much. I should probably use a semaphore or something... didn't really consider this when migrating away from the original async implementation.
That said... now I get timeouts on download... and it kills the whole process. I'm happy to post debug logs if that's helpful.
Yeah, definitely post them. I'd open a new issue though.