Curl error 6 getaddrinfo thread failed to start

Error: cURL error 6: getaddrinfo() thread failed to start error

Hi,

For the past 3 weeks, my site facing ‘cURL error 6: getaddrinfo() thread failed to start error’ again and again due to this error site facing multiple errors and went down. the host support team also working on it. Last night when I was working on mobile I face the above-said error, when I click on the error ➡please see the error link and 3 Screenshots:
https://paste.pics/deecb6d415cdfcd61cbdd915eead0129
https://paste.pics/80a56a4d69d9c2ae3f5d4ab0a1b61375
https://paste.pics/fab69317d0b09f218658964a6ef52a75

Since the above time, I deactivate the Google Site Kit plugin and so for the cURL error 6: getaddrinfo() thread failed to start error not show again.

If something wrong with the Google Site Kit plugin please fixes the issue or advice me on what and how to do it.

Thank you,
Best Regards,

The page I need help with: [log in to see the link]

Thanks for reaching out and sharing screenshots of the issue. As Site Kit was working for you previously if you’d like to share the following information I’d be happy to check your setup:

Your Site Health information. You can use this form to share privately.
Do you see any errors or notices when checking your Site Health status – which differs to your Site Health information above. I ask as the “JSON” related error on your primary Site Kit dashboard is a general WordPress error.
On your Site Kit dashboard whereby you see the “Not a valid JSON response” are there any browser console errors?

If something wrong with the Google Site Kit plugin please fixes the issue or advice me on what and how to do it.

Once we have the above information we may be able to determine more on this. cURL errors are typically hosting related although you may have third party plugins impact Site Kit functionality. I’ll provide some suggestions once we have the above information.

Let me know if you have any questions on the above.

Thanks for your reply and offer of support, I have sent all the information on your provided link.

Thank you,
Best Reagrds,

Many thanks for sharing the additional insights. As you seem to be using some plugins which may have configurations that could impact Site Kit functionality can you follow the steps below and share whether you encounter the same notice or error?

Login to your site from a Chrome browser incognito window
As you already have the Health Check & Troubleshooting plugin active navigate to “Plugins > Health Check & Troubleshooting > Troubleshoot”
From the same screen click on the “Available Plugins” tab at the top right and then click on the “Enable” option next to “Site Kit by Google”
Browser thought your Site Kit dashboards or check for the same notice once more

If the same notice occurs please share on what screen or at what stage you see this “cURL error 6: getaddrinfo()” notice, and share any console errors on that page.

I have check as you advise so I have not found the “cURL error 6: getaddrinfo()” notice but when I check console errors on the site kit page, I have found, please check the screenshot. https://paste.pics/3b1a5e1fd686e47d3a56627a024211d6

Thank you,

Great that this cURL related error no longer occurs, thanks for performing this check! Considering it no longer occurs what you can do next is enable your other plugins one by one while remaining in troubleshooting mode, checking for the same error message each time.

I ask the above as it seems there may be a third party plugin conflict impacting Site Kit in your case. If we can pinpoint the plugin I’m also happy to do some testing. While the issue no longer occurs in troubleshooting mode on your site it may reoccur once more if we can’t determine the cause.

In relation to the console error you reported I’ll check this with the team. Thank you for sharing! I’m unsure at this point why this may occur.

Let me know how you get on with the troubleshooting check above.

I reactivate one by one all the plugins and when reactivate the Regenerate Thumbnails plugin and upon checking in dashboard
‘cURL error 6: getaddrinfo() thread failed to start error’ shows again,
when I click Redo the plugin setup, the link opens as a googlesitekit-dashboard with an error see all 3 Screenshots.

After taking the screenshots I deactivate and reactivate the Regenerate Thumbnails plugin 2 times more but apart from 1st time “cURL error 6: getaddrinfo()” error not shows, and I Disable the Troubleshooting Mode.

Many thanks for performing those troubleshooting checks, I’ll test the same plugin on my side for any possible conflicts.

As you didn’t encounter the same error after further checks with Regenerate Thumbnails in troubleshooting mode can you inform me if the same occurs when you exit troubleshooting mode?

I’m also wondering is there something at host level impacting Site Kit operations, given there are other failed connections to WordPress.com services evident on of the screenshots you kindly shared. Do you have any other WordPress sites setup from the same hosting platform?

No, when yesterday I exit the troubleshooting mode I do not see again the error “cURL error 6: getaddrinfo()” and I have only one site with the host.

Now I check Google Site Kit again “cURL error 6: getaddrinfo()” occurs in the Site Kit dashboard, see the screenshots. https://paste.pics/370b9c1121fe8f11a713ffb5cc1292ee

When I deactivate the Regenerate Thumbnails plugin, see the result in the screenshots. https://paste.pics/cb0a061b3b1e338355afdf8c93b20cd3

Again when I reactivate the Regenerate Thumbnails plugin see the results in 2 screenshots one for Google Kit and one for the Regenerate Thumbnails plugin.
https://paste.pics/35028acca87f95ef4bc051698fc5c7e6
https://paste.pics/cb9b0b591e117ee1cc48e61849f1ebd0

Just now again happened when I open my site dashboard, when I click the, Redo the plugin setup, the link took me to the Google Site Kit, see the 2 screenshots.

Many thanks for sharing the additional insights. I’m after testing the same Regenerate Thumbnails and I’ve been unable to recreate any similar errors. I did encounter one console error on one occasion although this doesn’t seem related. I’ll continue to perform some additional tests, in particular with a combination of the plugins you have active.

As this may also be hosting related with other 500 errors to non Site Kit resources can you please perform the following checks while I check your site with the team?

Changing your PHP version temporarily (to a previous version available from your hosting control panel)
Using a clean WordPress install. You may be able to use a service such as Softaculous, which does seem possible with your current host. This may help pointpoint any hosting firewall or feature resulting in this notice

Let me know if you have any questions with the above.

Thanks for your reply and support. I keep in touch with the host support team for the past 10 days and they are working on all the matters, and this bellow is the latest reply from the host.

(((Upon further reading the response, I could understand that catch ‘cURL error 6: getaddrinfo() thread failed to start error’ occurs mostly in Google Site Kit, I have gone through the troubleshooting article of WordPress.org which you have shared and could understand better about the issue. As mentioned in the article I have checked the Site Health and I’m unable to notice any error. Furthermore, there were further troubleshooting steps that requires checking the website plugins, which has to be performed from the user end.)))

Thanks for providing an update. cURL errors are hosting related, with cURL being a tool to allow your website to communicate with other services, in your case the Site Kit service and the various Google services you connect.

So we can determine more on this can you perform the checks below and inform me if you encounter the same?:

Changing your PHP version temporarily (to a previous version available from your hosting control panel)
Check setup using a separate WordPress site. You may be able to use a service such as Softaculous, which does seem possible with your current host. This may help pointpoint any hosting firewall or feature resulting in this notice

Your advice and suggestion I pass to host, because point 1 and 2 is above to my skills, and I also offer if you need my site access I will able to pass you a login link.

Thank you for the update and offer! While we’re unable to login to users sites we are happy to test out your hosting platform or see if we can determine anything that may be impacting setup. Can you share what package you’re on? I noticed there is a free hosting plan, which we can test from our side.

I have a Bluehost Choice Plus Web Hosting package.

Источник

Error: cURL error 6: getaddrinfo() thread failed to start error

Hi,

Since the above time, I deactivate the Google Site Kit plugin and so for the cURL error 6: getaddrinfo() thread failed to start error not show again.

If something wrong with the Google Site Kit plugin please fixes the issue or advice me on what and how to do it.

Thank you,
Best Regards,

The page I need help with: [log in to see the link]

No problem at all, thank you for your willingness to perform these troubleshooting checks. In your Site Health information form I can see a reference to Flaunt7 hosting. Can you confirm this particular site is using Bluehost and no Flaunt7? It’s difficult to determine on my side as your site is pointing to Cloudflare servers.

Yeah, I’m sure my site hosting by Bluehost.

Thank you,
Best Regards,

My site went down on Saturday for 12/14 hours when I try to install WordPress on Softaculous. After restorations for the site is ok and in the past 3 days during my work I not face cURL errors but still facing an internal error.

Anu update from your side?

Sorry to hear your site went down after using Softaculous. I didn’t experience this previously so I can’t be sure. Thankfully it sounds like you had the technical expertise to restore it. May I ask was it the site you setup with Softaculous or was it your primary website, which was reporting issues?

In relation to testing on our side we initially performed tests using Flaunt7, as this was the hosting provider submitted in a Site Health information form for this topic. I believe another user filled in a form referencing this support topic, it references a different URL also. I did however perform some additional checks based on what looks like your own submission and it looks like your site is pointing to Cloudflare servers. Firstly can you share any errors you’re encountering when using Site Kit, whether it remains the “cURL error 6: getaddrinfo()” error or more insights on the “Internal error” you mentioned?

My site restore for me by the host team as another day above I mention I have very basic skills. The reporting issues one site, I set with Softaculous but soon after site went down. I have only this site.

Thanks for your kind support. I Hope, your kind work will bring good results.

Best Regards,

That’s great that is was restored. Now that your site is back up and running can you confirm the issue you’re encountering remains with the below error appearing on your Site Kit dashboard:
“Error: cURL error 6: getaddrinfo() thread failed to start error”

If so does this only occur with your “Regenerate Thumbnails” plugin active as before, or does this also occur in other circumstances?

The “Error: cURL error 6: getaddrinfo() thread failed to start error” appears 2/3 times in the past 60 hours, 2 times in the Site Kit dashboard, and one time on the site dashboard. Since the start, this error never appears in the “Regenerate Thumbnails” but one time catch when I activate the “Regenerate Thumbnails” plugin soon after the error shows in the site kit.

Thanks for the update. cURL error are hosting related and based on the console errors you’re encountering I would suggest speaking with your hosting provider. If you perform a Google search for this specific “cURL error 6” error you’ll find it can occur with any plugin that results in http requests.

You may also wish to perform thee additional checks, which may help determine the cause:

Switching PHP version
Checking does the same occur on a different site on the same hosting provider.

Note that I’ve also checked some of your reported console errors with the team and when you haven’t connected AdSense with Analytics this is expected.

Thanks for mentioning haven’t connected AdSense with Analytics, I have just done and so for no error shows in Sit Kit dashboard, and the rest of your suggestion I will keep in mind if “cURL error 6” error occurs again I will follow your advice.

Thank you so much for your kind times and support.
Best Regards,

And thank you for reaching out! While we haven’t been able to determine the cause it does seem server related, so please do attempt the above suggestions should you encounter this once more, and best of luck with your site going forward.

Yesterday and today again “Error: cURL error 6: getaddrinfo() thread failed to start error” occur in the WP site dashboard and when I click on the error link, they took me to the SIte Kit dashboard. But now, no internal error.

Thanks for the update. I’ll check this one more with the team and see if they can provide further insights. In the meantime I’ve reopened this support topic and I’ll see if I can find out more on this error. On your side can you perform the below checks?

Switching PHP version temporarily and checking for the same message?
Check does the same occur on a different site on the same hosting provider.

Thanks for the reply, since yesterday’s “Error: cURL error 6: getaddrinfo() thread failed to start error” occur I deactivate the Regenerate Thumbnails plugin because this has not been updated for the past 7 months.

But, now when I open the site kit dashboard just to check, all the sections are not loaded, when I try to find out via the developer tool, I found 43 errors even though the “Error: cURL error 6: getaddrinfo() thread failed to start error” not shows.

Thanks for sharing all these additional insights. From previous checks using the Regenerate Thumbnails plugins I don’t suspect a plugin conflict is the cause.

The “Response is not a valid response” error is a general WordPress REST API error. This may occur in a number of circumstances and I suspect in your case it’s linked with any hosting related issue. Something seems to be blocking requests form your wp-admin panel. Firstly do you see any notices when checking your Site Health status (which differs from your Site Health information?). There can be REST related warnings output here.

Secondly have you had an opportunity to perform any of the previous checks? I’ve added them below:
– Switching PHP version temporarily and checking for the same message?
– Check does the same occur on a different site on the same hosting provider.

Let me know anyway, hopefully we can get to the bottom of this! Appreciate all the troubleshooting steps you’ve taken so far.

Источник

Same issue on my machine (git version 2.28.0.windows.1).
The problem seems to be related to DNS resolution of HTTP-requests:

This was my original remote url:

git remote set-url origin http://<FQDN>:<http_port>/<repository>.git

With the same result as in the question:

$ git pull
fatal: unable to access 'http://<FQDN>:<http_port>/<repository>.git/': getaddrinfo() thread failed to start

When changing the URL to the resolved IP:

$ ahost <FQDN>
<FQDN>                               <IP>

$ git remote set-url origin http://<IP>:<http_port>/<repository>.git

Git connects without issue:

$ git pull
Already up to date.

Also, when using SSH instead of HTTP there is no issue with the resolution:

$ git remote set-url origin ssh://<username>@<FQDN>:<ssh_port>/<repository>.git
$ git pull
Already up to date.

Curl also doesn’t work in my MINGW64 environment:

$ ahost www.google.com
www.google.com                          172.217.2.100
    
$ adig www.google.com
id: 64322
flags: qr rd ra
opcode: QUERY
rcode: NOERROR
Questions:
        www.google.com .                A
Answers:
        www.google.com .        49      A       172.217.2.100
NS records:
Additional records:


$ curl www.google.com -v
* getaddrinfo() thread failed to start

* Couldn't resolve host 'www.google.com'
* Closing connection 0
curl: (6) getaddrinfo() thread failed to start

Источник

I had the same problem, I tried several solutions until I found out that in my case it was the firewall. Mine was the «Free Firewall», I noticed that even authorizing the software and connections it was still not possible to have a connection to the remote repository. I disabled it and it didn’t solve it, only when I uninstalled it that the problem was solved and I was able to use Git normally.

Same issue on my machine (git version 2.28.0.windows.1).
The problem seems to be related to DNS resolution of HTTP-requests:

This was my original remote url:

git remote set-url origin http://<FQDN>:<http_port>/<repository>.git

With the same result as in the question:

$ git pull
fatal: unable to access 'http://<FQDN>:<http_port>/<repository>.git/': getaddrinfo() thread failed to start

When changing the URL to the resolved IP:

$ ahost <FQDN>
<FQDN>                               <IP>

$ git remote set-url origin http://<IP>:<http_port>/<repository>.git

Git connects without issue:

$ git pull
Already up to date.

Also, when using SSH instead of HTTP there is no issue with the resolution:

$ git remote set-url origin ssh://<username>@<FQDN>:<ssh_port>/<repository>.git
$ git pull
Already up to date.

Curl also doesn’t work in my MINGW64 environment:

$ ahost www.google.com
www.google.com                          172.217.2.100
    
$ adig www.google.com
id: 64322
flags: qr rd ra
opcode: QUERY
rcode: NOERROR
Questions:
        www.google.com .                A
Answers:
        www.google.com .        49      A       172.217.2.100
NS records:
Additional records:


$ curl www.google.com -v
* getaddrinfo() thread failed to start

* Couldn't resolve host 'www.google.com'
* Closing connection 0
curl: (6) getaddrinfo() thread failed to start

Tags:

Git

Git For Windows

Источник

You might be wondering on what are we going to discuss in this article as it is most likely the case that you are seeing the error for the first time. But I found it very interesting, especially the whole debugging process I followed to figure out the actual root cause triggering above error. Going forward there are few software and command-line utilities that I mention to explain the context in detail. I have managed to provide hyperlinks to manual pages or websites for those utilities/terminologies I find may be useful for readers to go through and familiarize themselves with more insights.

Most of you might have heard about Samba software suite, which is an implementation of SMB protocol providing file and print services. As part of my daily job we have setup Continuous Integration(CI) nightly jobs to create RPMs out of upstream master branch. These jobs make use of mock software to build RPMs for Fedora, CentOS etc. At present we have jobs for building master code base, v4.14 and 4.15 of Samba for Fedora 34, 35 and CentOS 7,8. RPMs created out of these jobs are pushed to CI artifacts server as YUM repositories for easier consumption. Every job is run on a dedicated CentOS Linux 8(now CentOS Stream host allocated using specific tools from CentOS CI infrastructure. Following is a sample mock command that we use to create master branch RPMs for Fedora 35:

# mock --root /etc/fedora-35-x86_64.cfg --resultdir /tmp/samba-build/rpms/master/fedora/35/x86_64 --rebuild /tmp/samba-build/srpms/<samba.src.rpm>

Stoppage

Ever since we started creating RPMs for Fedora 35(on a CentOS Linux 8 host), we always encountered the following error from mock:

Errors during downloading metadata for repository ‘fedora’:

Curl error (6): Couldn’t resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-35&arch=x86_64 [getaddrinfo() thread failed to start]
Error: Failed to download metadata for repo ‘fedora’: Cannot prepare internal mirrorlist: Curl error (6): Couldn’t resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-35&arch=x86_64 [getaddrinfo() thread failed to start]
ERROR: Command failed:
# /usr/bin/systemd-nspawn -q -M 60d173130f8442799d437b8a889b5062 -D /var/lib/mock/fedora-35-x86_64-bootstrap/root -a –capability=cap_ipc_lock –bind=/tmp/mock-resolv.u51p8qri:/etc/resolv.conf –setenv=TERM=vt100 –setenv=SHELL=/bin/bash –setenv=HOME=/var/lib/mock/fedora-35-x86_64/root/installation-homedir –setenv=HOSTNAME=mock –setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin –setenv=PROMPT_COMMAND=printf “33]0;07” –setenv=PS1= s-v$ –setenv=LANG=C.UTF-8 –setenv=LC_MESSAGES=C.UTF-8 –resolv-conf=off /usr/bin/dnf –installroot /var/lib/mock/fedora-35-x86_64/root/ –releasever 35 –setopt=deltarpm=False –allowerasing –disableplugin=local –disableplugin=spacewalk –disableplugin=versionlock install @buildsys-build –setopt=tsflags=nocontexts
No matches found for the following disable plugin patterns: local, spacewalk, versionlock
fedora 0.0 B/s | 0 B 00:00
Errors during downloading metadata for repository ‘fedora’:

Curl error (6): Couldn’t resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-35&arch=x86_64 [getaddrinfo() thread failed to start]
Error: Failed to download metadata for repo ‘fedora’: Cannot prepare internal mirrorlist: Curl error (6): Couldn’t resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-35&arch=x86_64 [getaddrinfo() thread failed to start]

It is basically a curl error and we all normally doubt resolv.conf problems. But curl worked fine on the host system without any errors. We also checked other jobs and just Fedora 35 jobs were failing. So it has something to do with new Fedora 35. Additionally the very same job completed successfully on a Fedora 35 host(instead of CentOS Linux 8 host). We became curious on why it only fails on CentOS Linux 8.

Behind the scene

In order to further debug the issue, we have to get into the container systemd-nspawn creates for a Fedora 35 environment. For those of you who don’t know what systemd-nspawn containers are, read through the manual page for better clarity. In a nutshell it can be used as an enhanced chroot. Mock by default uses systemd-nspawn to create namespace containers for specific distro environments. As we can see from the error pasted in the above section one of the main argument to systemd-nspawn is the directory to be used as file system root for the container. There are many other optional arguments used to create a virtual file system hierarchy with process tree, IPC subsystems, domain etc. For our debugging purpose we could omit most of them to have a minimal Fedora 35 container environment without much complexities. To start with we need to have a directory to be used as file system root. Let’s use dnf to create such a root directory for Fedora 35 using –installroot argument as follows:

# dnf --installroot /var/tmp/f35-root --disablerepo='*' --enablerepo f35 --repofrompath=f35,https://kojipkgs.fedoraproject.org/repos/f35-build/latest/x86_64/ --nogpgcheck install strace

Please note that we install strace utility to analyze behind the scene calls while running curl command. On executing above dnf command we are presented with a Fedora 35 root at /var/tmp/f35-root. Now we instruct systemd-nspwan to spin up a namespace container with /var/tmp/f35-root as file system root with minimal arguments and present us with a bash shell.

# systemd-nspawn -q -D /var/tmp/f35-root -a --capability=cap_ipc_lock --bind=/etc/resolv.conf:/etc/resolv.conf --setenv=SHELL=/bin/bash --setenv=LC_MESSAGES=C.UTF-8 --resolv-conf=off bash

bash-5.1#

TA..DA! We are inside a Fedora 35 container. How about trying out curl command?

The culprit

bash-5.1# curl fedoraproject.org

curl: (6) getaddrinfo() thread failed to start

Oops.. there you go. The very same error we saw in mock output. What do we do now? Why is it failing? We now have strace utility to trace the calls. Let’s see what it tells:

bash-5.1# strace -o strace.log curl fedoraproject.org

curl: (6) getaddrinfo() thread failed to start

Searching through strace.log we could find a failure for the following syscall.

clone3({flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, child_tid=0x7f1b29620910, parent_tid=0x7f1b29620910, exit_signal=0, stack=0x7f1b28e20000, stack_size=0x7ffe00, tls=0x7f1b29620640}, 88) = -1 EPERM (Operation not permitted)

Woot..!! We have the culprit as clone3() syscall not allowed to execute inside the container. Further reading led us to the syscall filtering mechanism by systemd using seccomp filters. You can read more from kernel.org documentation.

Particulars

Fedora 35 comes with newer glibc v2.34. Curl utility when run tries to create threads which internally boils down to glibc calling clone3() syscall to achieve the purpose. This clone3() syscall is not in the allowed list of syscalls configured by systemd-nspawn. As per systemd-nspawn GitHub sources, it creates an allow-list containing different sets of syscalls defined by systemd. In recent versions of systemd, clone3() is part of @process set and is included within allow-list. For verification purpose we do have systemd-analyze command-line utility to display various sets of syscalls. But on an updated CentOS Linux 8 host we don’t see clone3() under @process set.

# systemd-analyze syscall-filter | grep clone3

systemd also maintains a @known set of syscalls. However the seccomp filtering rules are added inside systemd-nspawn in such a way that it returns EPERM(instead of returning ENOSYS by default) for all from @known set but not from allow-list. Thus on receiving EPERM for clone3(), glibc doesn’t fallback to others to deal with thread creation resulting in curl failure.

The end

Now that we know what is going wrong let’s see if we can deal with the issue using some workarounds or additional options to various components involved until fixed systemd version is available on CentOS Linux 8. We managed to find out following solutions to the problem:

Use –system-call-filter=clone3 to systemd-nspawn which adds the space separated list of syscalls or sets to the allow-list

# systemd-nspawn -q -D /var/tmp/f35-root -a --system-call-filter=clone3 --capability=cap_ipc_lock --bind=/etc/resolv.conf:/etc/resolv.conf --setenv=SHELL=/bin/bash --setenv=LC_MESSAGES=C.UTF-8 --resolv-conf=off bash

Export SYSTEMD_SECCOMP=0 to disable seccomp filtering within systemd

# export SYSTEMD_SECCOMP=0

# systemd-nspawn -q -D /var/tmp/f35-root -a --capability=cap_ipc_lock --bind=/etc/resolv.conf:/etc/resolv.conf --setenv=SHELL=/bin/bash --setenv=LC_MESSAGES=C.UTF-8 --resolv-conf=off bash

Refrain from using systemd-nspawn by mock. Instead use legacy isolation mechanism

# mock --root /etc/fedora-35-x86_64.cfg --isolation=simple --resultdir /tmp/samba-build/rpms/master/fedora/35/x86_64 --rebuild /tmp/samba-build/srpms/<samba.src.rpm>

I hope this helps someone who might encounter similar error in related environments. All commands from this article have been tried on an updated(till date) CentOS Linux 8 host. Feel free to add your suggestions as comments. Let this debugging saga be a motivation for others to get into details while trying to solve various issues. Bye..

Update: mock v2.16-1 got released yesterday with the second workaround mentioned towards the end of article which basically disables seccomp filtering within systemd. Updates are already in place and hopefully will be available with EPEL 8 stable repositories soon.

Источник

Posts
Oct 22, 2020 at 12:08 am

#3581711

Hello My website is having issues connecing to the host. I am constantly getting this error
cURL error 6: getaddrinfo()
Let me know if there is anything to get rid of that error.

Oct 22, 2020 at 12:36 am

#3581719

Hi there,

That message does not sound familiar, as our hosting here on WordPress.com is configured differently from other hosting providers.

Is this an issue with your following WordPress.com sites?

– https://sasjhnewsletter.home.blog/
– https://iamandrewpham133626651.wordpress.com/

If not one of those sites, is it possible you created your site under a different login? Is it the case that you are you using another provider like GoDaddy, Bluehost, Hostgator, etc. instead? What is the URL of the site you are needing help with?

Happy to check in our system so we can take a closer look.

The topic ‘cURL error 6: getaddrinfo()’ is closed to new replies.

Источник

Description

Stephen Kitt

2021-11-23 10:35:34 UTC

Description of problem:

On RHEL 8.4 (CSB), the following worked with fedora:34 but fails with fedora:35:

$ container=$(buildah from fedora:35)
$ buildah run $container -- dnf -y upgrade --nodocs --setopt=install_weak_deps=False
WARN[0000] error mounting subscriptions, skipping entry in /usr/share/containers/mounts.conf: getting host subscription data: failed to read subscriptions from "/usr/share/rhel/secrets": open /usr/share/rhel/secrets/rhsm/rhsm.conf: permission denied 
Fedora 35 - x86_64                                                                                  0.0  B/s |   0  B     00:00    
Errors during downloading metadata for repository 'fedora':
  - Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-35&arch=x86_64 [getaddrinfo() thread failed to start]
Error: Failed to download metadata for repo 'fedora': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-35&arch=x86_64 [getaddrinfo() thread failed to start]
error while running runtime: exit status 1
ERRO[0001] exit status 1


Version-Release number of selected component (if applicable): 35


How reproducible: 100%


Steps to Reproduce: see description above

Actual results: see above

Expected results: dnf upgrade runs correctly


This works if the build is run on a Fedora 35 system rather than RHEL 8.4.

Comment 2

Brian J. Murrell

2022-02-15 15:57:12 UTC

Any update here?  This happens with docker also.

Comment 3

Derrick Ornelas

2022-03-12 21:08:45 UTC

I'm running into this exact issue on Quay.io trying to build a F35-based image.  

At this point I'm fairly sure this is a duplicate of BZ 2009047.  @clems.verna @tsweeney seems like we could close this one out if you agree.

Comment 4

Tom Sweeney

2022-03-15 18:09:23 UTC

Seems like a dupe to me too, well spotted Derrick.  I'm fine with setting this as a duplicate.

Comment 5

Stephen Kitt

2022-03-16 09:37:31 UTC

*** This bug has been marked as a duplicate of bug 2009047 ***

Comment 6

Tilo

2022-04-08 22:38:21 UTC

@dornelas got this today on quay.io build. Do you know when the build nodes of quay will have this fix?

Источник

Error: cURL error 6: getaddrinfo() thread failed to start error

Error: cURL error 6: getaddrinfo() thread failed to start error

Tags:

Git

Git For Windows

Related

Stoppage

Behind the scene

The culprit

Particulars

The end

Читайте также: