The Dropwizard build fails sporadically on a network timeout to localhost. The test spins up a jetty web server on whatever free port is available. Then the test creates a client and makes a request, it uses the same free port picked. That request is what times out on travis-ci. We are not able to repro running locally, but happens with reasonable frequency on travis. Example failure below.
https://travis-ci.org/dropwizard/dropwizard/builds/76668866
Related
I am using jenkins-test-harness to run some tests on my jenkins library code, but when it executes the tests I get the following error for each test :
hudson.UDPBroadcastThread#run: Cannot listen to UDP port 33,848, skipping: java.net.SocketException: Can't assign requested address
The test will pass (if it should pass), but it then takes about 75 seconds for the jenkins server to shut down. I believe that these two are related, but I can't work out why I am getting this error. I have nothing else running on this port.
When I run the tests within a gradle docker container, rather than locally on the command line or inside the IDE (IntelliJ). This is very frustrating. While it does not change the result of the tests, it takes the running from about 10 minutes to over 1 hour and 15 minutes.
Am I missing a setting which is making this fail?
For me this was caused by Jenkins assuming that the default IP address it would be provided with would be IPv4 when in fact my machine was dual stack, preferring IPv6. I resolved it by ensuring that the integrationTest section of my build.gradle file had systemProperties 'java.net.preferIPv4Stack' : true. A bit like this:
integrationTest: {
/* other statements */
systemProperties 'java.net.preferIPv4Stack' : true
}
I must confess I saw no significant difference to my Jenkins shutdown time. I'd be interested to know if this resolves the error message, and if that resolves your overall issue.
Last week I set up a selenium grid using jenkins and 4 slave windows VMs. As part of doing this I had to unblock ports for both the slave connection and the selenium connection.
The vms downloaded the jnlp starter and registered correctly and by the end of the day Friday I had my tests running as reported as expected.\
Happy Monday, I come in to find out over the weekend that the connections to all four of the VMs have been lost due to connection timeouts. (the initial error indicated it had been terminated because the ping was too long, subsequent attempts never successfully connect in the first place.)
My research on SO so far points to issues with the ports, so I checked to make sure they are still enabled, and they are. Next I restarted the jenkins instance, and still no success.
Interestingly, the connection to the jenkins selenium grid IS working, each of the standalone servers starts and registers correctly on the VMs, and they are all able to access the jenkins ui from the browsers, just not able to register as a slave through jnlp.
At this point I am at a loss, I've mirrored the exact same setup that was working last week. I checked with our devOps team that manages the server and verified there have been no changes on that end. The VMs have been untouched.
Found a solution, but it leaves at least one question.
To resolve this I altered the Jenkins global security settings to use a fixed port for TCP connections and made sure it was one of my enabled ports, connection goes through cleanly now.
That said - this should NOT have worked on its own. When trying to connect earlier the logs clearly stated that connection attempts at the given port were refused (exact same port, and it was enabled then as well.)
I can understand if the agent was trying to connect at a different port, but I don't understand why dedicating the port itself would make a difference to the connecting agent.
I have a build running under Jenkins (Windows 7) that builds a C++ application. I wrote a small test app in python that runs the application after it is built and tests its networking capabilities. The problem is that the python script fails with
socket.error: [Errno 10061] No connection could be made because the target machine actively refused it
The test app works fine if I run it locally (it's only connecting on localhost 127.0.0.1) but it always fails when run under Jenkins.
I thought it was the firewall preventing the connection, but I discovered that the firewall has been turned off on the build machine.
I also have the Jenkins service logging in with an account that has admin access. I don't know where else to look.
Is it possible to run an app that accesses the local network during a Jenkins build?
Update:
As it turns out, my issue has nothing to do with networking, as far as I can tell. The C++ app tries to setup some DirectX9 services and is blocked from doing so under the user privileges provided by Jenkins. As a result, it quits before it even gets to setting up the networking. Now I have a different problem to solve.
I am new to jenkins.I need to create a jenkins job to check if port 80 responds to a http request with 200 and restart apache if it is not.Please advise.
You need Conditional Build Step and HTTP Request plugins.
Enable build step as condition in global configuration.
Setup a job with Conditional build step executing HTTP Request plugin, and on failure restart apache.
Restarting apache can be done through Publish over SSH plugin, or through Execute shell buildstep, if you are on Linux. If you are on Windows, you will need Execute batch command buildstep, and then use plink.exe that comes with Putty to connect to your apache server. This is all providing that your apache server is running on Linux in the first place.
If your apache is on Windows, that's a whole different can of worms.
You are not providing any information in your question, and as it is, it is too broad and shows zero research on your part.
We recently went through some network policy updates and I've discovered that my Jenkins server's jenkins service will no longer restart as expected (this worked fine prior to the policy updates).
There doesn't seem to be any logging information written on the service startup (no log files get updates).
Is there a list of external IPs that Jenkins needs to access in order to start up properly?
By looking at the logs, it seems as though part of the service start-up process is to contact one of the OCSP Servers. This seems to be related to certificate verification so it's probably legitimate traffic.
Once an exception was added for the target address (http://178.255.83.1:80), the Jenkins service started up without issues.