I have Jenkins running on Windows as a service. Normally, it starts when machine starts.
After a Windows recommended update this afternoon, and a machine restart, my Jenkins just stopped working.
I start the service but it stops and shows the following warning:
"The Jenkins service on Local Computer started and then stopped. Some
services stop automatically if they are not in use by other services or
programs."
There is no "jenkins.err.log" file and if I start Jenkins with "java jenkins.war" It works fine.
Any tip whats going on? How to fix this? Please help.
Thank you very much.
I had the same problem. It appeared that the java runtime enviromment had been updated. In the jenkins installation folder there is as jenkins.wrapper.log. This contains logging from the jenkins.exe service wrapper. In my case it tried to start java from c:\Program Files\Java\jre1.8.0_144\bin.
This folder did not exist, instead, java was installed in c:\Program Files\Java\jre1.8.0_161\bin.
In the jenkins installation folder there is also a jenkins.xml. This contains the reference to the java installation in the tag. Change it to your current java installation and it will start again.
I also had this problem after each java update. But there is a version-independent absolute path, that can be used to start the java run-time: C:\ProgramData\Oracle\Java\javapath\java.exe.
I changed jenkins-slave.xml to use this path:
<executable>C:\ProgramData\Oracle\Java\javapath\java.exe</executable>
if your java path is correct, disable RunawayProcessKiller in jenkins.xml
extension enabled="**false**" className="winsw.Plugins.RunawayProcessKiller.RunawayProcessKillerExtension"
If the java.exe path is setup correctly in the jenkins.xml/jenkins-slave.xml file and the problem persists, then try to delete the jenkins_agent.pid file and restart the service.
In my case this happened after I installed some updates on my machine. After some research (jenkins.err.log) it turned out that some other application grabbed the port 8080 that was used by Jenkins up to this point.
I managed to identify the app (with TcpView) and disabled it.
Problem solved.
In my case, I installed JDK 17.0.2, but Jenkins requires version JDK 8 to 11.
Check error log under C:\Program Files\Jenkins\jenkins.err for exect error.
My issue was installation of an (unwanted) service that also listens on port 8080. That service failed to start on installation because Jenkins was running at the time, but after a reboot the rogue service started more quickly and nabbed the port. The fix was to disable the unwanted service.
from jenkins.err.log:
java.net.BindException: Address already in use: bind
Caused: java.io.IOException: Failed to bind to 0.0.0.0/0.0.0.0:8080
Your first stop should be the Windows Event Viewer logs to get a better idea of the underlying error. In my case the error read:
Service cannot be started. System.ComponentModel.Win32Exception (0x80004005): Access is denied
at System.Diagnostics.ProcessManager.OpenProcess(Int32 processId, Int32 access, Boolean throwIfExited)
at System.Diagnostics.Process.GetProcessHandle(Int32 access, Boolean throwIfExited)
at System.Diagnostics.Process.OpenProcessHandle(Int32 access)
at System.Diagnostics.Process.get_Handle()
at winsw.Plugins.RunawayProcessKiller.RunawayProcessKillerExtension.OnWrapperStarted()
at winsw.Extensions.WinSWExtensionManager.FireOnWrapperStarted()
at winsw.WrapperService.OnStart(String[] args)
at System.ServiceProcess.ServiceBase.ServiceQueuedMainCallback(Object state)
You can examine your Jenkins configuration by looking at jenkins.xml. In my case this included configuration for a RunawayProcessExtension which terminates previous instances of Jenkins before starting the new instance. The <pidfile> entry stores the location of a text file with the PID of the last known instance of Jenkins.
In my case, this <pidfile> was pointing to a PID that was no longer used by a running Jenkins process. Instead, that slot had been taken over by a system process (csrss.exe), causing the RunawayProcessExtension to throw an exception with an "access denied" message when trying to terminate it. Jenkins itself was not starting because it was expecting the RunawayProcessExtension to terminate first.
The solution was to delete the <pidfile> and then restart the service.
It is happing as Jenkins is not able to find java(jdk) path. check jdk path in jenkins.xml file
Resolved this issues
java -version
where java
check jdk/bin -- copy this jdk path
Goto jenkin.xml file and change java path
To resolve this problem follow bellow steps -
Open window task manager(use CTRL + ALT + Delete button)
Navigate to service on the task manager
Click 'Services..' button on task manager
Services window gets opened > Search the Jenkins service and re-start/Start the Jenkins service
Refer Image - Jenkins Service
Now try accessing the Jenkins, problem re-solved
Jenkins service might be stoped.Find the jenkins service in window services and click start.I tried it many times.It worked
I have a fresh install of Jenkins 2.32.2 on Ubuntu.
Opened a browser on the instance and get to a page titled Offline, with the message "This Jenkins instance appears to be offline" and offers options to "Configure Proxy" or "Skip Plugin Installation"
The machine clearly isn't offline as I just used the internet connection to do the installation.
I also had a previous installation, done exactly the same way, that was working.
I removed the previous installation as Pipelines wouldn't work and Google told me it was because of JDK 9. So I removed all the JDK/JRE installations as well as jenkins, fresh installed JDK 8 only, installed Jenkins, and got to here.
Jenkins has worked on this box in the past so what makes it think it is offline?
Update: Found a log file /var/lib/jenkins/logs/tasks/Download metadata.log
and it starts with a message FATAL: Connection refused (Connection refused)
I would think that indicates that the internet connection is OK, but something else is stopping it getting data?
Update: Based on other research I checked the Update Site in the Plugin Manager. This is listed as http://updates.jenkins-ci.org/update-center.json and, from the command line a wget of this file succeeds. So most definitely not a connection issue. Worked with both http and https, jenkins works with neither.
In my case, it has something to do with SSL. I manage to fix it by editing /var/lib/jenkins/hudson.model.UpdateCenter.xml and change url to use http instead of https.
Restart jenkins and reload the website, it no longer shows offline.
For macOS users:
Step -1: Edit /Users/Shared/Jenkins/Home/hudson.model.UpdateCenter.xml and change url to use http instead of https.
Step -2: Restart jenkins (for instance by going to http:localhost:8080) and reload the website
Step -3(Optional): If it asks for user and password and if you don't remember creating one; default user is admin and copy the password from
sudo cat /Users/Shared/Jenkins/Home/secrets/initialAdminPassword
credits - #Alex in this post and #Tuan Pham here and #Joe Walsh for the comment on macOS directory path
There is something wrong with the internet connection of update center.I have met the same situation with Jenkins installed on macOS.
You can try to modify the hudson.model.UpdateCenter.xml file.
Jenkins installed with .pkg package on macOS,the file path is:
/Users/Shared/Jenkins/Home/hudson.model.UpdateCenter.xml
Jenkins installed by Homebrew on macOS,the file path is:
/Users/{username}/.jenkins/hudson.model.UpdateCenter.xml
Open the file:
<?xml version='1.1' encoding='UTF-8'?>
<sites>
<site>
<id>default</id>
<url>https://updates.jenkins.io/update-center.json</url>
</site>
</sites>
You can try to change https://updates.jenkins.io/update-center.json to:
http://updates.jenkins.io/update-center.json
or
// If you are in China or near China area,https and http are both OK.
https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/current/update-center.json
And then you can restart Jenkins by:
//loading the URL to restart Jenkins.
http://localhost:8080/restart
or
// Use Homebrew command to restart Jenkins if you installed Jenkins LTS version by Homebrew.
brew services restart jenkins-lts
in my case (macOS), updating jdk to 8 and reinstall jenkins solved the problem.
The issue is that for some reason Jenkins doesn't have access to the certificates chain of the Jenkins updates service.
On Ubuntu 18.04 I had this issue and the next links and instructions helped me to start Jenkins properly without modifying the default url or using a proxy of some sort.
Installing a new JDK 8(u101+) with JAVA_HOME should do the trick like at:
https://www.digitalocean.com/community/tutorials/how-to-install-java-with-apt-on-ubuntu-18-04
is making sure that Lets Encrypt certificates are installed and available on the OS/SYSTEM.
To test it you can use the instructions at:
Does Java support Let's Encrypt certificates?
And to install manually if required the Let's encrypt root chain using the next script:
https://gist.github.com/Firefishy/109b0f1a90156f6c933a50fe40aa777e
I also faced this issue i.e. This Jenkins instance appears to be offline on windows 10.
Below are the steps I followed to solve it:
Navigate to the Jenkins Home Directory.
For me, the default home directory is: C:\Windows\System32\config\systemprofile\AppData\Local\Jenkins.jenkins
Changed the protocol from HTTPS to HTTP in the file hudson.model.UpdateCenter.xml
Restarted Jenkins (Go to C:\Program Files\Jenkins and then execute jenkins.exe stop, jenkins.exe start)
Logged in to Jenkins again (http://localhost:8080/).
The offline error got solved.
In my case i have changed https to http in URL line of /var/lib/jenkins/hudson.model.UpdateCenter.xml file
and restarted the jenkins. It started functioning.
in case you are running jenkins in a container and vi is not installed
access your container in interactive mode
docker exec -it jenkins-ci /bin/bash
use this sed command to replace https with http
sed -i 's/https/http/g' /var/jenkins_home/hudson.model.UpdateCenter.xml
This mostly happens when you are working with company issued PC Windows OS.
Fix :-
click on "Configure Proxy" ask your IT team for specific server and port values that can bypass firewall and give your windows username & password. In this way you can resolve windows firewall and offline Jenkins issue.
I researched a lot over Internet but nowhere the fix is available.
Thanks!
For Ubuntu,
go to /home/username/.Jenkins/Hudson.model.UpdateCenter.xml and
edit the file from https to http.
On MacOS 10.11.6 :
Go to /Users/<UserName>/.jenkins
Open the file hudson.model.UpdateCenter.xml
Change the value of default from https://xxx to http://xxx
Took note of the secret Administrator password path that Jenkins displays when first opening http://localhost:8080/ on a browser.
The path was: C:\Users{username}\AppData\Local\Jenkins.jenkins\secrets.
Therefore the hudson.model.UpdateCenter file was at C:\Users{username}\AppData\Local\Jenkins.jenkins\
Updated the hudson.model.UpdateCenter file in notepad to have text http instead of https as follows:
http://updates.jenkins.io/update-center.json
Reloaded the http://localhost:8080/ page but still showed the text "This Jenkins instance appears to be offline."
Then navigated to the Services App in Windows (click Windows and type 'Services App' and it should display the App in the search list)
In the services App right clicked the Jenkins service and selected Restart.
After Windows restarted the Jenkins service navigated to http://localhost:8080/
The Jenkins page wouldn't even load. Navigated to the Jenkins login page: http://localhost:8080/login?from=%2F
Then got a loading page with text:'Please wait while Jenkins is getting ready to work ...
Your browser will reload automatically when Jenkins is ready.'
Assumed that Jenkins was still restarting.
Once the Jenkins login page loaded, entered that password/secret again and clicked Continue.
This time the page with "This Jenkins instance appears to be offline." was not displayed. Jenkins displayed a Getting Started -> Customize Jenkins page with buttons to install plugins.
For Windows OS,
follow below steps:
Go to C:\Users\\*your user name*\\.jenkins
Open the file hudson.model.UpdateCenter.xml
Update the value of url from https://xxx to http://xxx
I make no claims about this, especially Java related (I personally cannot stand the language), but on my Ubuntu 18.04 L/T, I needed to stand-up a standalone Jenkins instance; So I installed both the Java on which Jenkins appears to be dependent and Jenkins itself
sudo apt install openjdk-8-jdk jenkins
Then I updated the Jenkins defaults
sudo gvim /etc/default/jenkins
... inserting the following at the top of the file - only because editing /etc/init.d/jenkins appeared to serve no purpose as it had no effect whatsoever ...
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/
PATH=$JAVA_HOME:$PATH
Finally, save & quit ... then attempt Jenkins restart
sudo service jenkins restart
HTH - it certainly worked for me :-)
I'm working on a Mac, and in my case, it turned out that the version of Java Jenkins was using (1.8.0u66) wasn't up to date enough. I had both Java 11 and Java 14 installed, but the jenkins-lts script was coded to force use of Java 8. Rather than install a more up to date JDK 8 installation, I modified the script to run ${JAVA_HOME}/bin/java and set JAVA_HOME to the JDK 11 installation.
It might not always be an option but if you have a choice use different Image. I used Debian GNU/Linux 10 and it worked like a charm.
Re-installing JAVA JDK8 worked for me.
Another possibility - make sure DNS functions properly for Jenkins.
In my case, I followed Kubernetes setup instructions here to install Jenkins, and it led to this problem.
I enabled logging on CoreDNS and saw this:
│ [INFO] 10.70.116.14:45888 - 50490 "AAAA IN updates.jenkins.io.svc.cluster.local. udp 54 false 512" NXDOMAIN qr,aa,rd 147 0.0001896s │
│ [INFO] 10.70.116.14:45888 - 32566 "A IN updates.jenkins.io.svc.cluster.local. udp 54 false 512" NXDOMAIN qr,aa,rd 147 0.000169468s │
│ [INFO] 10.70.116.14:57907 - 22912 "A IN updates.jenkins.io.localdomain. udp 48 false 512" NOERROR qr,aa 110 0.000907476s │
│ [INFO] 10.70.116.14:57907 - 52100 "AAAA IN updates.jenkins.io.localdomain. udp 48 false 512" NOERROR qr,aa 110 0.001709031s
The lookups were all cluster-local.
If I edited the URL (as suggested in other answers here) to include a dot after updates.jenkins.io. then hostname lookup worked and the URL resolved. Though Jenkins' next step errors for the same reason.
In the end I discovered the problem was ClusterFirst mode of the pod's DNS. I added dnsPolicy: Default to the deployment's pod template spec (the instructions link above), and now it works.
Even I faced similar issue, then figured out that JDK that I was using is 8 instead of 11.
Check jenkins jdk combination under jenkins official site
I used JDK11 with Jenkins 2.3031 version and it worked fine - all plugins got downloaded
In my case, I use WINDOWS OS. So, jenkins was installed in my C drive.
PATH : C:\Users\Username\ .jenkins
Under "hudson.model.UpdateCenter" file change "https" to "http"
<?xml version='1.1' encoding='UTF-8'?>
<sites>
<site>
<id>default</id>
<url>http://updates.jenkins.io/update-center.json</url>
</site>
</sites>
As some others pointed out, in Windows, this could be because of firewall restrictions set by company infrastructure.
For my case, I need the recommended plugins to be present (e.g. Folders plugin)
My workaround was:
A. Install same Jenkins version into my personal laptop/VM, and be sure to install the recommended plugins the first time you browse to the Jenkins Web Page.
B. Copy the plugins folder from my personal laptop's JENKINS HOME folder (i.e. ProgramData\Jenkins...) into the Jenkins plugins folder of the company laptop.
Total size of the plugins folder was around 150MB (zipped).
Enter this before running Jenkins.
# iptalbes -F
It may be because of the firewall.
jenkins_enable="YES"
jenkins_home="/usr/local/jenkins"
jenkins_user="jenkins"
jenkins_args="--webroot=${jenkins_home}/war --httpListenAddress=*.*.*.* --httpPort=8180"
#jenkins_java_opts="-Djavax.net.ssl.trustStore=/usr/local/jenkins/cacerts -Djava.net.preferIPv6Addresses=true"
#jenkins_java_opts="-Djavax.net.ssl.trustStore=/usr/local/jenkins/cacerts -Djava.net.preferIPv4Addresses=true"
I am trying to use the new feature of PHPStorm, which is to develop PHP app using docker.
I have installed the docker integration plugin for PHPStorm, when I try to define the Clouds settings, I get this error:
cannot connect: com.github.dockerjava.api.NotFoundException
I have checked the app, and its running in the browser normally at:
http://192.168.99.100:8090/
I didn't specify the certificates folder, as I am using http not https locally.
Any idea? I am on windows 10, I have installed jdk-7u79-windows-x64, I tried both 32, 64 versions, I got the same error..
Although the machine is up and running..
Try that:
The fastest way to connect is via ssh to the interpreter(Like vagrant):
Follow: https://hub.docker.com/r/jorge07/php7-xdebug-ssh/
Once machine is up:
Add remote interpreter:
Languages & frameworks > PHP
(Note that php executable in on: /usr/local/bin/php)
Now add a sftp service:
Build, Execution, Deployment > Deployment
Connect to machine by ssh and map your code folder with the /app folder on interpreter container.
Once you finish, you are done. Good luck!
I have this project having MSSQL 2008 R2 as its database server. The connection between the Services view of IReport and the database is established and running. The problem here is that the project cannot connect to the database server when running it.
These is the error showned on grails console prior to start-up completion:
ERROR hbm2ddl.SchemaUpdate - could not complete schema update
I've seen similar case but the way to resolve it is having the driver sqljdbc4.jar put inside the [Project Name]\classpath\Grails Dependencies (project explorer heirarchy) where the driver is located in the [Project Name]\lib. But the do how has gone missing.
I've also tried to manually install the dependency following the commmand below but grails return that the driver is not found.
grials> install-dependency sqljdbc4
The question is how can I include the driver into the Grails Dependencies?
Assuming you are running Grails 2+, this article should help you. I also had to restart Eclipse before everything actually showed up correctly.