The out-bound network connections fail on my Docker client (mac version), after running for an extended period of time. I'm running Docker on my mac (non-beta version of Docker, with the latest version of Sierra).
I launched a set of containers via Docker-compose, which connect to various web-services. The connections start out fine, with no issues, but then fail the very next day. That is, if I run a script like this: data = requests.get("http://www.nytimes.com"), it works perfectly when I launch the containers, but fails with a timeout error the next day. Moreover, if I attempt to rebuild the containers (stopping docker-compose), I see several DNS failures. BUT, my host system (my mac) is running fine, with no obvious problems. If I then restart the Docker client, everything works correctly.
Any suggestions would be welcome.
Related
To test our desktop application we have a Master project that runs the Slave project on different VMs.
We are using TeamCity to start our tests. On a TestManagement machine (VM) we have a Build Agent that is running as Service. This Build Agent starts the Master project with TestExecute.
This project connects with RDP to different VM to run our UI Tests (Slave project) of our App. We are using Network Suite and run our tests on Hosts (VMs) like it is suggest here: Using Network Suite.
But we have an issue with the screen resolution that is used to run our UI Tests. The resolution is too low.
This page Running tests via RDP gives an explanation:
"When running tests on a remote computer that participates in distributed testing, TestComplete creates a Remote Desktop session and automatically sets the master computer's screen resolution on the remote computer. This is done to avoid possible problems with test running."
So TestExecute will use the master computer's screen resolution.
But TeamCity Agent is run as a service on a VM (TestManagement machine) and there is no screen resolution because it's an headless machine and not like a real user that will connect with RDP to this VM and start the Master Project.
I assume TestExecute will then use the default screen resolution (something like 640x480) as the resolution for the RDP connection. But this is too low to run our tests, some object are not on the screen and we have many issues...
Is there a way to change the resolution used by the RDP connection that TestExecute / TestComplete will create ?
The tricky part is that the Master project is started from a service on an headless machine...
Thank you for your answers,
Camille
In the past, we experienced a similar problem as yours and we were unable to solve it by this way. As solution (right now working for us) we installed into our test environments the TightVNC. This able us to forget the screen connection (RDP issues) because you configure the screen resolution by RDP the first time, then access via IP, log in and you will be able to launch whatever you want without open any application.
Maybe its not the best solution but for our testing environments we can launch tests from Jenkins on demand without screen resolution problems.
I'm trying to introduce continuous integration in an old project, and we've got quite specific situation - it's possible to put the CI server only on our test server that runs on CentOS. The server has quite a lot of unused RAM and CPU capability.
However, we need to run Ant builds on Windows (this also used to be how the project did packaging before), however it turned out that not the same output (after binary compare) is produced by just using Unix versions of Java and Ant.
I drew up a diagram of how in my mind it could work, but I'm really wondering whether that is even possible (with already given tools).
The black part is implemented, I'm curious whether the red part could be possible. Could the Jenkins slave communicate with master on different OS?
It should be possible. I have a feeling you will need to play with your network settings. But if before you start changing anything see if you can start a headless slave by following these directions: https://wiki.jenkins-ci.org/display/JENKINS/Step+by+step+guide+to+set+up+master+and+slave+machine
Using VirtualBox for CentOS, it will possible to run a Windows VM on your CentOS host.
I'm not sure you need Docker to launch your Jenkins slave.
It maybe better to use a standard JNLP Windows service to connect your Windows slave to Dockerised Jenkins master.
If the master is not able to view the Windows node using this method, you may have to tweak your network configuration on the Windows VM.
But I'm not sure it's necessary.
I've a Windows Server 2012 R2 based Hyper-V Host, which contains a Windows Server 2012 R2 VM as a VPN using RRAS and another VM running Debian plus the Jenkins (latest version) master server. Using this VPN, a private hosted Windows Server 2012 R2 VM act as Jenkins slave using those VPN connection. For better distinction, call this one node1.
This is bascially working as expected, but there is a problem: Sometimes, when I start a buildjob on node1, it hangs. Only the first 2 steps (Started through user XYZ and Build on slave node1 in workspace C:\jenkins are shown in the log, then nothing happens. On the master, the node1 is shown as online and is connected to the VPN.
Currently I start Jenkins using a windows task. Using this method, the above happens only sometimes. But as I configured the server, I tried to solve this in a cleaner way by registering Jenkins as Windows Service. As Windows Service, I had the same behavior: In the web panel Node1 is shown as online, but when I start a job on it I only come to Build on slave node1 and then it stops.
Normally the next step should be fetching the latest source code from my git repo. I already had the problem but now found out that it has something to do how Jenkins is started. But for me it seems very strange because running the slave as a Windows Service hasn't worked at least one time, and by running it as a Task it works most of the time.
I only found out that the problem also occurs when I start a job directly after node1 boots. When I then cancel the hanging Job and start it again, it seems to work for a while.
There are few options that I can think of them. According to Jenkins Wiki
If the slave is supposed to start desktop applications you have to
allow the service to interact with the desktop
(Action->Properties->Logon->Allow service to interact with desktop).
Another option can be that Windows services don't have the ability to interact with the windows desktop, meaning that some UI tests might no work as you expect. Do any of the steps may need interacting with the desktop (Windows GUI)?
Just for the sports how about to setup a temporary clean windows server to act as node2 (Jenkins slave) and to check if the problem is been reproduced?
I'm trying to run a SikuliX Script 24/7 on a VPS but I do not want to leave my computer on all the time while it runs. I know sikuli requires that you have a monitor, so I am not sure how I can have it run while my VPS isn't even open on my computer.
If your VPS is running Linux you could use a tool such as Xpra, it allows for an X application to be run even when the client disconnects. It can also be used with a nested X server like Xephyr to run a full remote desktop that persists disconnects.
On Windows Server this this superuser page details how to allow a Windows Server RDP session to persist even after the client has disconnected.
I am getting serious access problems every single time I take a Windows snapshot from the EC2 console. After taking the snapshot neither the original machine, nor the images snapshot, are avaialable. And by this I mean that there is no RDP, HTTP or HTTPS connectivity, all of which were accessible ports before the snapshot. There is nothing to explain why this error occurs, as the sys logs are either blank or seem to show a successful snapshot and machine launch. Note that I have also had scenarios where I reboot the machine and again NOTHING is available.
What am I doing wrong? These are the steps I take.
1) Launch a default Win2k8 with IIS7 image. This is my machine: ami-c5e40dac
2) Install .NET 4.0
3) Activate the database (turn on the service).
4) Install my application and the database. This include an HTTPS certificate (I think I read somewhere that Windows has a restart problem if a cert is in the machine store - WTF?)
5) Take a snapshot or reboot --- Bang, everything is dead!
Anyone come across such problems?
I had a similar problem earlier this week; it turned out that my instance was just taking an age to boot (1 hour +).
Is it possible that you had some pending windows updates that wanted to run on startup?