I have a python script which use rest-api to communicate with my server.
I am using python-requests to handle rest-api.
The script has a loop and try-except for handling errors to keep it running.
On centos, I accidentally mis-configured the dns and started my script.
Here is the error:
HTTPConnectionPool(host='host.com', port=80): Max retries exceeded with url: //rest/url (Caused by NewConnectionError(': Failed to establish a new connection: [Errno -2] Name or service not known',))
Then I reconfigured the dns properly without restarting the script, but the script still didn't work unless restart it. Same error.
Programs started after dns reconfiguration like ping, web browsers were working fine.
Same problem happens for ping if it is started before dns reconfiguration, but not for firefox.
It seems that firefox took a while to adapt new dns configuration.
On debian, this problem does't exist.
When I reconfigured the dns properly, the script or other programs started to work almost immediately.
Is there anything special with dns on centos?
Can my script adapt new dns configuration without restarting?
==========================
python-requests version I tested:
2.11.1, 2.12.4, 2.13.0 On centos
2.11.1, 2.12.4 on debian
centos version tested:
6.2, 7.3-1611
debian version tested:
debian-sid latest update
python version:
2.7.13rc1 on debian
2.7.5 on centos 7.3-1611
2.6.6 on centos 6.2
problem solved by calling __res_init in glibc.
More details see Python not getting IP if cable connected after script has started and http://bugs.sugarlabs.org/attachment/ticket/1940/network.py.patch
Related
I have already installed rstudio server and shiny-server on my ubuntu machine (ec2 aws). I usually code in rstudio server, drop the scripts of my shiny applications in /srv/shiny-server and go to the url of the application to see it and everything works.
Since a few days I want to go through gitlab ci/cd for versioning and to automate my work, however when I run my gitlab-ci.yml I get this error :
Being new to CI/CD, I'm having a really hard time and I'd like your help if possible. Thanks
I've successfully completed the ./install.sh command. When I run the next "~/mcdev start -o" I receive this error: "Starting Microclimate
Pulling microclimate-file-watcher (ibmcom/microclimate-file-watcher:1809)...
ERROR: Get https://registry-1.docker.io/v2/ibmcom/microclimate-file-watcher/manifests/1809: net/http: TLS handshake timeout
Error starting Microclimate"
I have running on my pc:
git version 2.17.1 (Apple Git-112); Docker version 18.06.1-ce; MacOS
High Sierra v 10.13.6; latest Microclimate v18.09
My network is up and I don't have any proxy.
What am I missing or doing wrong?
I got this to work by changing to a different wifi \ internet connection. Still not sure why my home wifi, with no restrictions that I'm aware of, will 'block' the dependency downloads upon start of Microclimate.
If anybody has additional info to help find the root cause please feel free to share.
This docker error generally shows up when your internet connection is too slow for Docker, as it times out performing the TLS handshake. This would also explain why moving to another network fixes the issue.
My Cygwin installed on Windows 7 was working properly till I try to install a new package. The package installation failed. Then I keep getting this error every time I want to run my Open MPI program. I can successfully compile the program but cannot run it. I even remove and make a new installation without success.
Thanks for any hints. Below is the sample error message.
[Reloaded-PC:03900] [[3921,1],0] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
[Reloaded-PC:03900] [[3921,1],0] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
[Reloaded-PC:04676] [[3921,1],2] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
[Reloaded-PC:04676] [[3921,1],2] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
The problem is solved by disabling the unused network adapter in "Control Panel->Network and Internet->Network Connections".
It turned out the unused network adapter tried to get configured by DHCP and an IP address started with "169.254.X.X" was assigned to this adapter when DHCP fails. Somehow openmpi on Cygwin use that invalid IP address for establishing communication between processes.
I figured it out by looking at /tmp/openmpi-sessions-{username}/{PID of orterun}/contact.txt.
I had this same problem on Cygwin with OpenMPI 1.10.4.
Try adding "-report-uri -" to your mpirun command to see what IP address it's trying to use for connection:
mpirun -report-uri - -np 2 a.exe
It should print out a line that looks something like this:
568328192.0;tcp://192.168.10.103,169.254.247.11,0.0.0.0,0.0.0.0,0.0.0.0:55600
If the first IP address after the "tcp://" is not a current valid address for your machine, that's the problem and things are likely to break (even if the correct IP appears later in the list). Apparently ORTE is not smart enough to order the interfaces based on what is actually enabled and online.
If the wrong IP corresponds to an old/disabled interface, uninstall it (if possible) using the windows network connections control panel.
In my case, the first address was a DHCP address for an old hardware adapter I'd removed and thrown away long ago (but apparently not uninstalled in software). Windows normally hides such removed-but-not-uninstalled interfaces in the control panel, but the settings remain in the registry under:
HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\
Search in that registry subkey for the bogus IP address and you are likely to find the problematic interface. I fixed mine by changing the IP address in that registry key to match my current static IP, but uninstalling the interface entirely would probably also work.
I had the same problem with openmpi v 1.8.8 (which is the default version of the package installed by cygwin). Manually going back to version 1.8.6 fixed the issue for me.
I just encountered this problem and in my case I had to disable the "VirtualBox Host-Only Network" adapter (I recently installed virtualbox and have not used openmpi in cygwin after that until today).
1. Open the Cygwin terminal.
mpicc --version
mpirun --version
If not execute, follow the document below and reinstall everything. Document
2. Try turning off Bluetooth and test your program again.
3. Try closing the Wifi and test your program again (you can connect to the wired internete)
4. Open C:\Windows\System32\drivers\etc\hosts
add line
127.0.0.1 localhost cygdrive wpad
and test your program again.
5. If you have a virtual network like VirtualBox or similar, turn off the control panel and test your program again.
6. If possible, uninstall VirtualBox completely. Restart your computer and test your program again.
7. Try turning off the Windows Firewall and test your program again.
The above steps solved both the "tcp_peer_send_blocking: send () to socket 12 failed: transport endpoint is not connected" error and the slowness problem in MPI for Windows 10 - Cygwin.
I have installed xampp on linux (command line version with no gui).
I am using Amazon Linux AMI.
The installation is successful and i got xampp up and running.
$ sudo /opt/lampp/lampp start
Starting XAMPP for Linux 5.6.14-4...
XAMPP: Starting Apache...ok.
XAMPP: Starting MySQL...ok.
However i am not able to access the xampp ui from browser.
I am accessing http://(public ip of the linux ami)
Is there anything else required to access the ui.
I did some R&D around the problem and found out that the security group (linked to the amazon instance) did not allow http traffic.
Edited security group to allow http traffic and issue was resolved.
XAMPP UI can be accessed now using the public DNS or public IP.
I have a fresh, text-only installation of openSuSe 13.1 (physical server, old Samsung netbook), and I'm trying to get OTRS up and running. I've installed OTRS using the below commands. I don't think they're all necessary, but someone in the OtterHub forums had a successful installation with the software versions I'm targeting using this sequence, so I was trying to piggyback on that success.
zypper in otrs-3.3.4-01.noarch.rpm gcc make mysql-community-server perl-Crypt-SSLeay perl-JSON-XS perl-YAML-LibYAML
zypper in perl-Text-CSV_XS perl-PDF-API2 perl-GDGraph perl-Encode-HanExtra postfix perl-DBD-mysql
cd ~otrs && bin/otrs.SetPermissions.pl --otrs-user=otrs --web-user=wwwrun --otrs-group=www --web-group=www /opt/otrs
rcmysql start
systemctl start apache2.service
mysqladmin --user=root password password
All of that works fine. I'm able to get to the OTRS web installer, but that's where I get hung up. I get to the part of the web installer that creates the database, and it times out. The script successfully creates the database and updates Config.pm with the new password. I can't tell from installer.pl what it tries to do next.
Here's the error from /var/log/apache2/error_log:
[Tue Jan 28 20:53:23.136306 2014] [cgi:warn] [pid 6856] [client 192.168.1.10:52732] AH01220: Timeout waiting for output from CGI script /opt/otrs/bin/cgi-bin/installer.pl, referer: http://svr-clptest/otrs/installer.pl
[Tue Jan 28 20:53:23.136470 2014] [cgi:error] [pid 6856] [client 192.168.1.10:52732] Script timed out before returning headers: installer.pl, referer: http://svr-clptest/otrs/installer.pl
The browser displays the following:
The gateway did not receive a timely response from the upstream server or application.
This is on a local network at home. I'm accessing the Linux server using PuTTY from a Windows 8 machine. I'm using a wireless connection from the Windows 8 machine, but the server has a hard line connection to the router, if that makes any difference. I don't have any trouble executing anything from PuTTY or accessing the index page through the browser (Firefox 26). I've tried connecting from a computer on my network, and one off of my network. In both cases, I'm able to get to my domain and the web installer. But I can't make a PuTTY connection to the server from outside my network.
I've spent a couple of hours researching the error, and I can't figure out what the next step should be.
Right now, a text-only version of openSUSE and OTRS are the only things running on the machine. I haven't done anything else with it. I'm open to starting the installation from scratch again--OS and all. I'm thinking that the timeout error has something to do with my firewall settings, but I'm not a network guy. Really have no idea how to diagnose this.
UPDATE
I tried reinstalling everything fresh tonight, but then added KDE so I could walk through the web installer on the host. I get exactly the same errors. It's not a problem between server and client. Something's wrong with OTRS... Or maybe with apache?
I eventually just had to follow the steps for manual installation instead of using the web installer. Not sure where the problem was exactly, but no matter what I tried, I couldn't get the database setup to work through the web installer. If you're having a similar problem, once you get to the part of the instructions that tell you to move to the web installer, you can switch over to the instructions to install from source and pick it up from manual installation of the database.