We're trying to connect a previously connected agent to a Jenkins server.
We get the following error:
SEVERE: https://jenkins.domainname.com/tcpSlaveAgentListener/ appears to be publishing an invalid X-Instance-Identity.
java.io.IOException: https://jenkins.domainname.com/tcpSlaveAgentListener/ appears to be publishing an invalid X-Instance-Identity.
at org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.resolve(JnlpAgentEndpointResolver.java:287)
at hudson.remoting.Engine.innerRun(Engine.java:694)
at hudson.remoting.Engine.run(Engine.java:519)
The command to run the agent is:
java -jar agent.jar -jnlpUrl http://${private_ip}:8080/computer/mac/slave-agent.jnlp -secret ${secret} -workDir "/var/jenkins-sign"
We're running on a MacOS.
All TCP ports are open internally between the mac and the ${private_ip}. I have telnet working.
As said, this agent was recently connected to the server, but the agent had a restart. We also upgraded the Jenkins server to latest available version.
I updated the agent.jar file.
I think it's related to contacting ${private_ip} while the X-Instance-Identit says "jenkins.dommainame.com", but I am not sure how to resolve it.
I only saw that there were recently changes in this area, but not a lot of helpful information other than that.
Does anyone have an idea?
In case anyone else runs into the issue, in my case it was because I was passing the entire URL, i.e.
http://someurl/jenkins/computer/test/slave-agent.jnlp
and what it really wanted was
http://someurl/jenkins/
Unfortunately, I think it's related to Jenkins upgrade that caused this, and I'm not sure there's a better solution than what I found.
Putting here my solution, but if anyone knows something better, I'd be happy to hear about it :)
Download the agent.jar
Download the slave-agent.jnlp and modify it:
Change all occurrences of https://jenkins.mydomain.com to http://[private_ip]:[port].
Start the process: java -jar agent.jar -jnlpUrl "file:/path/to/dir/slave-agent.jnlp" -workDir "/path/to/dir"
Do not add the secret to this command.
If you're using Jenkins agent as a service, remove the -secret argument from the file.
Set global environment variable jenkins.agent.inboundUrl to your private adderess (with http/https) + port + suffix (if set).
This value will be used as url in JNLP file. This enables using a private address for inbound tcp agents, separate from Jenkins root URL.
see: https://issues.jenkins.io/browse/JENKINS-63222
I want to add a new slave to Jenkins. When I followed the Jenkins UI, it gives me the command below
java -jar agent.jar -jnlpUrl http://<jenkins_url>/computer/<slave_name>/slave-agent.jnlp -secret 4b59708a20e155c8ccb39f1fb046be09f72c712ed839401195c475d5fdb2b0e5
When I tried to execute that command, its output like below:
Exception in thread "main" java.lang.IllegalArgumentException: IV buffer too short for given offset/length combination
at javax.crypto.spec.IvParameterSpec.<init>(IvParameterSpec.java:80)
at hudson.remoting.Launcher.parseJnlpArguments(Launcher.java:515)
at hudson.remoting.Launcher.run(Launcher.java:325)
at hudson.remoting.Launcher.main(Launcher.java:283)
Could you please help me about this error? Any help will be appreciated. Thanks in advance.
Best Regards.
I reviewed the setting of the IV length in Jenkins code as well as in the Jenkins agents code (remoting) and it seems to be consistently set to 16 bytes everywhere.
However, by running curl to GET the slave-agent.jnlp URL ($JENKINS_URL/computer/$node_name/slave-agent.jnlp), I found that the http:// URL which I thought I should be using returns just "302 Found" with the "location" header set to the same URL but with https://. curling that, I saw messages about missing permissions in Jenkins (to Read, then to Connect agents). Adding those for anonymous users (at $JENKINS_URL/configureSecurity, using matrix-based security) resolved that issue for me.
Or rather, it turned it into another issue, which was "Connection refused". It took me another while to figure out that -- for our Jenkins master running in a container -- in the Global Security configuration, "TCP port for inbound agents" must be set to the container-internal port, while in the node configuration, "Tunnel connection through" has to be set to the external port.
I hope my debugging exercise will be at least partially applicable in your context, too.
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"
When I try to install a Windows service:
c:\Windows\Microsoft.NET\Framework64\v4.0.30319\installutil
I get, what looks to be, some success messages and some failure messages. Part way down:
An exception occurred during the Install phase.
System.ComponentModel.Win32Exception: The specified service has been marked for deletion
At the end:
The Rollback phase completed successfully.
The transacted install has completed.
The installation failed, and the rollback has been performed.
The service is given an entry in the Services applet, but it is marked as "Disabled". When I attempt to change it to another state, I get a "marked for deletion" error message.
There are no messages in the Event Log. There is nothing useful in the log file created by installutil.exe (I believe it's written to the current working directory).
I have no direction to go with this. What do I do?
It turns out that the install might, or probably will, fail if that service is highlighted in the Services applet. It's safest to just close the Services applet, install the service, and then re-open the Services applet. It's really stupid.
Also, make sure to run the console as admin.
I experienced the same and the issue for me was that a service with the same name was already installed. So in order to install the new service I had to uninstall the older services. I am learning how to create and setup windows services and thus the naming conflicting. Tried uninstalling the service first through:
c:\Windows\Microsoft.NET\Framework64\v4.0.30319\installutil -u servicename.exe
Once this statement executes successfully, install your service and it should succeed without any rollbacks.
Right Click on Command Prompt and choose RUN AS ADMINISTRATOR
Then copy and paste in: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe C:\TestService\bin\Debug\TestService.exe
Result in TestService.InstallLog is:
Installing service TestService...
Service TestService has been successfully installed.
Some times this happens due to permission issues.
Run the "Developer Command Prompt for VS 2012" as Administrator.
Then it will work.
Adding few more check's and points to solve this above issue.
Build service in release mode and take release folder files and kept in different path
Copy that path and go to visual studio command prompt window and run this bellow sample command to install the service.
Please close services.msc window if its opened , then run C:Program Files (x86)\Microsoft Visual Studio 11.0>InstallUtil.exe C:\RunLocationServices\TestService.exe
Go services.msc and select that service and click on start ,if it changed to "started" then your service running fine.
Still if issue exists then
Another Checkpoint & SOLUTION
When a service starts, the service communicates to the Service Control Manager how long the service must have to start (the time-out period for the service).
If the Service Control Manager does not receive a "service started" notice from the service within this time-out period,
the Service Control Manager terminates the process that hosts the service.
This time-out period is typically less than 30 seconds.
If you do not adjust this time-out period, the Service Control Manager ends the process.
To adjust this time-out period, follow these steps:
1.Go to Start > Run > and type regedit
2.Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
With the control folder selected, right click in the pane on the right and select new DWORD Value
3.Name the new DWORD: ServicesPipeTimeout
4.Right-click ServicesPipeTimeout, and then click Modify
Click Decimal, type '180000', and then click OK
5.Restart the computer
Still if issue exists then problem in your service code ,infinate loop may occur due to your methods/classes of service calling. Do code review of each line.
This problem is due to security, you'd better open developer command prompt for VS 2012:
RUN AS ADMINISTRATOR
and install your service. It will surely fix your problem.
I tried and the issue was resolved.
I have followed this link to run Selenium Server as a windows service: http://www.claytonstechnobabble.com/2011/08/run-any-application-as-windows-service.html
The service gets installed successfully but when I try to run it it gives error:
"The SeleniumRC service on Local Computer started and then stopped. Some services stop automatically if they are not in use by other services or programs."
can you guys help me on that asap? what am I missing?
This is the selenium server file that I am trying to run: "selenium-server-standalone-2.5.0.jar"
Ali, you might try capturing the output from the service. Since the Java app is designed to be run in console mode, there is likely to be some useful explanation if you can capture std out and std err. Running the service with a wrapper like Java Service Launcher will provide that functionality to log the error information: http://jslwin.sourceforge.net/
Create a bat file containing
//cd Location of file
java -jar selenium-server-standalone-2.5.0.jar
then use this bat file to execute in service.