There is a problem with ./build update

the problem is the same with my server. no problem with connection but always curl timeout
our last result :
Code: 
[root@server custombuild]# ./build set_fastest
Testing with file 10.kb:
0 B/s   - files.directadmin.com
24955 B/s       - files2.directadmin.com
0 B/s   - files-fi.directadmin.com
0 B/s   - files-fr.directadmin.com
0 B/s   - files-lt.directadmin.com
0 B/s   - files-de.directadmin.com
0 B/s   - files-sg.directadmin.com
0 B/s   - files-ca.directadmin.com
Total test duration: 38 seconds

Small file test took longer than 35 seconds.  Not proceeding with large file test.
Fastest server is files2.directadmin.com at 24955 B/s
downloadserver is already set to files2.directadmin.com

==
 Executing /usr/local/directadmin/plugins/custombuild/admin/build update_script...
#=#=# ##O#-# ##O=# # #=#=-# # -#O#- # # -=#=# # # -=O#-# # # -=O=# # # # -=O=-# # # # -=O=- # # # # -=O=- # # # # -=O=- # # # # -=O=- # # # # -=O=- # # # # -=O=- # # # # -=O=- # # # # -=O=- # # # # -=O=- # # # # -=O=- # # # # -=O=- # # # # -=O=- # # # # -=O=- # # # # -=O=- # # # # -=O=- # # # # -=O=- # # # # -=O=- # # # # curl: (28) Resolving timed out after 5000 milliseconds
Warning: Problem : timeout. Will retry in 1 seconds. 3 retries left.
==

wget -qO- bench.sh | bash

 Node Name        Upload Speed      Download Speed      Latency
 Speedtest.net    1782.02 Mbps      938.84 Mbps         0.35 ms
 Los Angeles, US  161.84 Mbps       59.49 Mbps          255.96 ms
 Dallas, US       159.12 Mbps       246.15 Mbps         281.79 ms
 Montreal, CA     133.16 Mbps       259.23 Mbps         283.26 ms
 Paris, FR        269.74 Mbps       263.77 Mbps         188.07 ms
 Amsterdam, NL    198.86 Mbps       274.29 Mbps         264.86 ms
 Shanghai, CN     3.26 Mbps         253.34 Mbps         387.69 ms
 Nanjing, CN      144.53 Mbps       213.85 Mbps         375.75 ms

It seems to be a problem with the resolvers defined in /etc/resolv.conf but we have to change using free dns resolver not solved this problem

Google8.8.8.88.8.4.4
Quad99.9.9.9149.112.112.112
OpenDNS Home208.67.222.222208.67.220.220
 
update: last try, we remove all resolver from /etc/resolv.conf and its running well now :eek: .. can anyone explain ?
 
bdacus01 said:
It probably Systemd related. Systemd trys to control everything now. Whats the OS?
Click to expand...
CloudLinux 7 OS Shared Pro. cloudlinux claim its in my network or firewall and not related with cloudlinux :D .. not explain why without dns resolver everything its working right now
 
What do you see with

Code: 
systemd-resolve --status

whats in
Code: 
/etc/systemd/resolved.conf
 
bdacus01 said:
What do you see with

Code: 
systemd-resolve --status

whats in
Code: 
/etc/systemd/resolved.conf
Click to expand...
[root@serverxx ~]# systemd-resolve --status
-bash: systemd-resolve: command not found
[root@serverxx ~]# more /etc/systemd/resolved.conf
/etc/systemd/resolved.conf: No such file or directory

thanks for your response
 
bdacus01 said:
You must have removed systemd-resolve
Click to expand...
You sure about that? If I run the command systemd-resolve --status on my normal Centos 7 machines I also get the "systemd-resolve: command not found" notice. No /etc/systemd/resolved.conf present either.
So seems to me it's not required. Maybe Cloudlinux takes care of resolving some way without the /etc/resolv.conf for some reason, I don't know.
But I do know that I did not remove them either.
 
Richard G said:
You sure about that? If I run the command systemd-resolve --status on my normal Centos 7 machines I also get the "systemd-resolve: command not found" notice. No /etc/systemd/resolved.conf present either.
So seems to me it's not required. Maybe Cloudlinux takes care of resolving some way without the /etc/resolv.conf for some reason, I don't know.
But I do know that I did not remove them either.
Click to expand...
I think so too, but cloudlinux said that the problem is not part of cloudlinux and asked me to coordinate with the network admin :D

resolver handled by localhost

[root@server22xx ~]# nslookup google.com
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
Name: google.com
Address: 74.125.24.139
Name: google.com
Address: 74.125.24.102
Name: google.com
Address: 74.125.24.100
Name: google.com
Address: 74.125.24.113
Name: google.com
Address: 74.125.24.101
Name: google.com
Address: 74.125.24.138
Name: google.com
Address: 2404:6800:4003:c03::65
Name: google.com
Address: 2404:6800:4003:c03::66
Name: google.com
Address: 2404:6800:4003:c03::8b
Name: google.com
Address: 2404:6800:4003:c03::8a
Click to expand...
 
You first used 8.8.8.8 and 8.8.4.4 but that is not the smartest idea because Google has some limits one can run into and then resolving does not work anymore. Doesn't happen often but it does happen.
In that case if you have your own resolver, it's best to use 127.0.0.1 and then 1.1.1.1 as second in /etc/resolv.conf for things to work fine.

I hope that helps.
 
for my case, /etc/resolv.conf its should be empty and problem its solved. we are using using bind and 3 dns cluster.
 
Yes we've seen, but Linux normally uses the /etc/resolv.conf to look up things. It's not empty when it contains 127.0.0.1 so it could have been the Google limits I was talking about.
 
You must log in or register to reply here.
Back
Top