Temporary failure in name resolution

[dylanparry]

Affected Version

yay v11.3.0 - libalpm v13.0.1

Describe the bug

I'm getting an error when trying to retrieve updates from the AUR. Up until I check for updates, my Internet connection is working just fine and I'm able to browse websites etc. As soon as I check for updates, I get the following error:

dial tcp: lookup aur.archlinux.org: Temporary failure in name resolution

Then I am unable to browse webpages, pings stop responding, and traceroutes don't work. After several minutes my connection works properly again. NetworkManager shows I am still connected for the entire time that this is happening.

Reproduction Steps

1. yay -Syyu --combinedupgrade --nodevel --singlelineresults (I have this aliased to upgrade)

Expected behavior

I'd expect to see a screen like this:

If there updates, it would list them here of course, but I ran it just now there were no updates to do.

This is what I'm actually getting though:

and am then unable to use my Internet connection again for several minutes, or until I disconnect and reconnect my WiFi.

Here's the output of yay -Pg

{
        "aururl": "https://aur.archlinux.org",
        "buildDir": "/home/dylan/.cache/yay",
        "editor": "",
        "editorflags": "",
        "makepkgbin": "makepkg",
        "makepkgconf": "",
        "pacmanbin": "pacman",
        "pacmanconf": "/etc/pacman.conf",
        "redownload": "no",
        "rebuild": "no",
        "answerclean": "",
        "answerdiff": "",
        "answeredit": "",
        "answerupgrade": "",
        "gitbin": "git",
        "gpgbin": "gpg",
        "gpgflags": "",
        "mflags": "",
        "sortby": "votes",
        "searchby": "name-desc",
        "gitflags": "",
        "removemake": "ask",
        "sudobin": "sudo",
        "sudoflags": "",
        "requestsplitn": 150,
        "completionrefreshtime": 7,
        "maxconcurrentdownloads": 0,
        "bottomup": true,
        "sudoloop": false,
        "timeupdate": false,
        "devel": false,
        "cleanAfter": false,
        "provides": false,
        "pgpfetch": true,
        "upgrademenu": true,
        "cleanmenu": true,
        "diffmenu": true,
        "editmenu": false,
        "combinedupgrade": false,
        "useask": false,
        "batchinstall": false,
        "singlelineresults": false,
        "separatesources": true,
        "version": "11.3.0"
}

I realise this isn't much to work on, but please let me know what other things I can provide and how to get them :)

[grandchild]

That's interesting. It seems like something in your network (or your ISP's network) blocks you for a few minutes after doing something "bad"?

Is it only sometimes that this happens? Does it happen on another network? E.g. you could, if you have the data plan for it, try tethering to your phone and doing the request there.

If it's really the URL in the error message that is the "Bad Thing(TM)" you get punished for, it should happen the same if you just curl $URL.

It could be a previous network request though, and from the looks of it the previous thing that happens is the official package update. Maybe try switching pacman mirrors?

[dylanparry]

Yes, it seems to be only sometimes. I've tried running it with my phone tethered, and it didn't seem to happen then, although admittedly it is sporadic anyway so it could just be I didn't try enough times.

I noticed that my mirrorlist hadn't been updated since last year, which is odd because reflector.timer is supposed to be managing that weekly. I ran reflector manually and updated the list, and that seemed to work at first, but after a few runs it's hanging again.

I think you're right though that it's happening before the AUR check. Loading that URL again and again in my browser doesn't cause the issue I'm having, so the failure to be able to fetch it by YAY must be a symptom rather than the cause.

Out of curiosity, I ran yay -Syy on its own without checking the AUR. It ran fine several times in a row, then suddenly wasn't able to connect to the servers and timed out. It doesn't seem to matter which mirror I'm using, this sometimes happens with all of them.

[grandchild]

Can you try if the same happens with vanilla pacman? It sounds like it's something that the normal requests from pacman would trigger as well.

I think if it shows that pacman is doing this too, then I will close the issue. But we can continue discussing and debugging here, if only because I'm curious what's going on. 🙂

[dylanparry]

Yep, looks like it's a pacman problem. I ran sudo pacman -Syy a few times in a row until it inevitably hanged:

So yeah, it's definitely not a YAY problem!

[grandchild]

Have you checked on your router to see if there's any messages about disconnected internet there? They might include some diagnostics.

[dylanparry]

There's nothing I can see, unfortunately. Other devices connected to the same router continue to function just fine when these "outages" occur though; it's only my laptop that loses access for a few minutes.

[grandchild]

Can you determine on which layer you get cut off? Can you ping the router IP? Can you ping a public internet IP like 8.8.8.8? What does ip ro say?

[dylanparry]

Ping to an IP address appears to work, as does pinging the router. Interestingly, I also tried pinging a domain name and got this:

The highlighted line occurred at the same time as the update (very) briefly appeared to hang at the "Searching AUR for updates..." step, so I'm guessing the Internet connection was interrupted at the previous step.

ip ro shows:

[grandchild]

Hm I don't think a 45ms increase in ping time is anything else but a short congestion in network usage (possibly on wifi layer) from the AUR update. If it were hundreds of msecs or seconds, that might be something, but this is very tiny.

It's all very weird and I can't really put my finger on it, except it sounds like it's the router that is punishing you for... something. I'm afraid I'm a bit out of my depth here. I'd search online for other people with the same router experiencing network blockage/disconnects. Maybe it's something specific to your model/firmware? Some safety/protection mechanism kicking in? Hard to say...

[dylanparry]

Yeah. It's a strange one. I wouldn't have thought much of the ping either, it was only because I was also running the 8.8.8.8 and 192.168.0.1 pings at the same time, and saw no spike there at all, that I even thought to mention it. FWIW, no pings outside the network work at all when it totally hangs on me (I can still access the router control panel for example, but not any web sites).

I honestly have no idea what's going on here either. It only started recently, and nothing on my network has changed in months. It seems to only affect this laptop too, no other devices.

I imagine it'll suddenly stop being an issue at some point too, knowing my luck, and I'll never find out what caused it 😂

Thanks for your help anyway though 👍