I'm using Jenkins 2.15 (GitHub plugin 1.29.3) based CI for my GitHub core repo. It works fine, but sometimes Jenkins build doesn't update GitHub check status.
I see nothing relevant into Jenkins log.
Any idea how to debug and hopefully fix this issue?
As I know, check status update is just an http request to the status api: https://developer.github.com/v3/repos/statuses/
I experienced a similar behavior with a database. The client application and the database had no errors. Each one was on a different host.
What I did was, create a bash script in host A to perform a ping to host B.
ping www.host_B.com | while read pong; do echo "$(date): $pong"; done >> /tmp/ping-test-$(date +%F).log
Then, when the sporadic error related to the connection of the database occurred, the log file helped me to detect that the error was related to:
Network issues
Latency issues
Internet service provider issues
In your case, you could perform a simple curl to the status api and compare to the sporadic behavior detected.
Related
I am running apache beam java pipeline and for some reason getting lots of warning logs in GCP.
I tried changing log level of packages java.net,sun.rmi to SEVERE but still no success.
Logs are getting polluted with these warning messages. Any one else facing the same issue ?
jsonPayload: {
exception: "java.net.SocketTimeoutException: Accept timed out
at java.base/java.net.PlainSocketImpl.socketAccept(Native Method)
at java.base/java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:458)
at java.base/java.net.ServerSocket.implAccept(ServerSocket.java:551)
at java.base/java.net.ServerSocket.accept(ServerSocket.java:519)
at java.rmi/sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:394)
at java.rmi/sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:366)
at java.base/java.lang.Thread.run(Thread.java:834)
"
logger: "sun.rmi.transport.tcp"
message: "RMI TCP Accept-5555: accept loop for ServerSocket[addr=0.0.0.0/0.0.0.0,localport=5555] throws"
Pipeline is simple : Pubsub to Postgres. No additional third party connectivity.
Please refer to public documentation about troubleshooting.
Select the job to view more detailed information on errors and run results. When you select a job, you can view the execution graph as well as some information about the job. Then, click the Logs button to view log messages generated by your pipeline code and the Dataflow service.
Another thing, that you can use is debug option. When running the gcloud command, you can include the option --verbosity=debug to get debugging output.
This might be related to a JVM bug. Please check Java SDK version snd upgrade to a newer (2.17.0 or higher) version.
Additionally, check Encoding errors, IOExceptions, or unexpected behavior in user code error.
I hope you find the above pieces of information useful.
I couldn't figure out the actual issue but in the mean time since it was polluting the logs traces added flag in pipeline options:
--workerLogLevelOverrides={"sun.rmi.transport.tcp":"OFF"}
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.
I have tfs installed locally on my machine. It used to work fine but for a week or so now, it does not work most of the time.
It is not possible to connect from Visual Studio 2013 now using the team menu item. It is able to connect only once in so many tries.
Git Fetch, Git Pull and Git Push commands from Git Bash take a long time to show the login prompts and sometimes does not even working reporting that it could not connect to localhost:8080
Fetch, Push and Pull from Visual Studio work once in a while.
Connecting with the web always works though sometimes slow.
Git Push with Git Bash and Gui of late gives the error below
POST git-receive-pack (8010 bytes)
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly
error: RPC failed; result=7, HTTP code = 0
Pushing to http://localhost:8080/tfs/col1/_git/project1
Everything up-to-date
I've read so many articles and now seem to work. Is there a way to troubleshoot TFS to find out where it is coming from so that it can be corrected.
It turned out this had nothing to do with TFS as generally requests that have to do with local host fails most of the time. It may be an issue with the system when it comes to local host. In any case, I disabled IPv6 and it still didn't work.
What worked however was rawcap. I realized that when I run rawCap to monitor 127.0.0.1, all calls were going through successfully. It appears something it did rectified the issue. Hope it helps someone who also had the same issue with localhost.
Watch for -1 statuses in TFS Activity Log (http://localhost:8080/tfs/_oi). Right click -> Show Detail to get the full exception. Also look for errors in the IIS logs.
I tried to deploy a Play app to Cloudbees (only via push to git repo from which it is built by jenkins), it compiled and should work but I get a "502 Bad Gateway" error when loading the app. There is no error shown in the console only that it answers "502 Bad Gateway" when trying to access it. But that's what I see in the browser, too.
Cloudbees say that there is no other manipulation necessary, just cloning/pulling the ClickStart-Project, making it you application and pushing it back. The Play project works fine locally.
I am very grateful for any help. Please let me know if I need to provide any other information. Thanks a lot!
Edit: It works fine with Heroku only adding a Procfile. I don't get the problem with Cloudbees...
In this case the error is due to the database needing evolutions to be run before it can start:
[warn] play - Run with -DapplyEvolutions.default=true and -DapplyDownEvolutions.default=true if you want to run them automatically (be careful)
Oops, cannot start the server.
#6eg39l651: Database 'default' needs evolution!
You can see the error in your application console:
https://run.cloudbees.com/a/strehlst#app-manage/logs:strehlst/odzh
or via bees app:tail if you have the bees CLI installed.
You can also deploy direct from your desktop if you like:
play dist
bees app:deploy -t play2 dist/yourapp.zip
And it will push direct to your app (if you don't want a continuous deployment pipeline).
I am having a problem launching my (grails) project to cloud foundry. I have already launched with cf-push, but I keep getting this error
I/O error: Connection reset; nested exception is java.net.SocketException: Connection reset
when I run cf-update.
I also cannot see my log files with cf-crashlogs. I get this in the terminal window:
grails> cf-crashlogs
| Checking for available resources:.....
And if I try to access the page I get a 404 Not Found page.
Did I completely miss something? has anyone else seen this or know how fix this issue?
please check which version of the cf grails plugin were you using. try listing the plugin updates with this command:
grails list-plugin-updates
after that try to get cloud foundry connection info by:
grails cf-info
i suppose you know how to configure the login info, all the configure properties are listed here: http://grails-plugins.github.com/grails-cloud-foundry/docs/manual/guide/3%20Configuration.html
to access your app log, the most commonly used command is
grails cf-logs [destination] [--appname] [--instance] [--stderr] [--stdout] [--startup]
hope that helps.
I was trying to test Cloud Foundry long time ago. Don't remember but also had some issues which I couldn't overcome using default tool.
However then I used the Cloud Foundry Integration.
As I mentioned it was some time ago, so I won't help with the details, but the plugin worked as expected and I was able to deploy. Maybe you will success with it too :)