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.
Related
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 know I posted a question that was bogging me for days but found a solution for it just 5 minutes after posting so I am posting about this problem that I get ever since 2 hours, anyway, I have a job in Jenkins that executes a series of commands remotely via SSH but before there is a connection establishment it throws me this error: com.jcraft.jsch.JSchException: channel is not opened, on my topology I have the Jenkins server in my main pc and I want to communicate with a CentOS 7 VM, on my jenkins I have configured everything (the SSH agent on global configuration for example), on my CentOS 7 VM I don't think that there's a need to open the port 22, my expected results are obviously the possibility to execute the script (let's begin by connecting), my VM has the ip of 192.168.127.129, if you want another information you can ask me by commenting, thanks in advance
I did not resolve the problem, however my VM was in host only connection, I changed it to NAT and problem solved but it isn't a permanent one nor best practice, now my VM is connected to the internet and is exposed to all of its dangers
I am getting below error when trying to access jenkins pipeline url. I tried clearing the browser cache, tried different browsers etc but no luck. the same pipeline url works fine for other users but not for me. any ideas why it throwing 404 error for me? many thanks!
HTTP ERROR 404
Problem accessing /job/jenkins/job/test/. Reason:
Not Found
Powered by Jetty:// 9.4.z-SNAPSHOT
After loging in as an administrator, use the url http://localhost:8080.
It initially takes to the url that says jenkins in it's name, which will not work. The URL you want to access is http://localhost:8080
Also if you have a different port binded you can try to call the url as http://[ip]:[port]/jenkins
If you get such error like it was mentioned above you should access through the URL "http://localhost:8081/jenkins/", but not only "http://localhost:8081".
Btw my port is 8081 because of the circumstance that my 8080 port is already used.
Have a good day!
There can be probably one of these reasons :
You do not have the access to the job.
You do have access to the job but you are not logged in . Try to login to jenkins in another window and check remember me on this computer , then open that url.
You are trying to access it from another server which is not whitelisted from the jenkins master server ,i.e it is not allowed access.
These are the best guesses I coud get .If these do not work then someone needs to manually check the url you are entering and other environment related issues themselves.
There is a common mistake that most of the people making.(while running jenkins.war from CMD)
Please ensure that your tomcat server is 'up and running' locally.
Follow these steps.
try restarting your jenkins service with $sudo service jenkins restart
I have faced the same issue and identified JIRA and Jenkins are installed on same port 8080. Jenkins service is starting first because of that JIRA was not working. Then I have edited Jenkins.xml file with port 8081 and restarted the services it was working fine.
When I ran jenkins.war from CMD, I faced the same issue. Practically when you run jenkins.war from CMD, localhost:8080 is where jenkins is available. But if you run the startup.bat file, then the path you have set, say, localhost:8080/jenkins will work.
If you are using a hook this error occurs. This is a known issue in GIT showing 404 error. Way around of the above said problem is to use the NIC ID instead of using "localhost".
I used a docker container to start jenkins locally for a test purpose.
Here is the cmd: docker run -p 8080:8080 -p 50000:50000 jenkins reffered to official documentation: https://hub.docker.com/_/jenkins?tab=description.
After started the container, I browsed into http://localhost:8080 and got
HTTP ERROR 404
Problem accessing /job/jenkins/job/test/. Reason:
Not Found
Powered by Jetty:// 9.4.z-SNAPSHOT
I just removed exposing the JNLP port which is 50000
And the command to start docker was: docker run -p 8080:8080 jenkins
And now, I was able to browse the application at http://localhost:8080 without not found error.
Thanks
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
On Jenkins configuration page in section "Jenkins URL" I've set this option to "http://name_of_my_machine.jenkins:8080/"
Usually I open jenkins by: "http://localhost:8080/"
But this new option did not work for me - Jenkins does not open. So what does it mean?
Jenkins can't determine its URL on its own. So when it needs to create full links that's where the URL is taken from. In general even if you specify the wrong URL it should not affect the way Jenkins works in any significant way. It certainly has no effect on the URL that you enter in your browser to connect to Jenkins server. You can either specify http://localhost:8080 (when connecting from your machine and assuming that you started Jenkins on port 8080) or http://<machine_hostname>:8080 when connecting from anywhere.
So no matter what you specify it has no effect on connecting to Jenkins, therefore http://name_of_my_machine.jenkins:8080/ won't work, as .jenkins is not part of the name (e.g. ping name_of_my_machine.jenkins won't find the host).
Whenever Jenkins needs to create a URL that points to itself, Jenkins picks it up from the "Jenkins URL" setting in the global configuration.
Jenkins could try to guess the URL by e.g. getting the hostname and combining that with the port it is running on. But sometimes the hostname is not the same as the DNS name. And what if you have placed a front-end or proxy before Jenkins that e.g. terminates SSL connections and you would really like people to use Jenkins at https://company.com/jenkins/. Jenkins running in port 8080 cannot know about the front-end. The only reliable way for Jenkins to get the URL to itself is for an administrator setting it in Jenkins configuration.
Jenkins needs to know it's own URL when it is creating links that point back to itself. It does this e.g. when it sends out emails containing direct links to build results. Also, if you have a JNLP type slave, the slave initiates the connection to the master and the master returns a message which contains a link back to Jenkins for downloading the slave agent software.
Do you mean the option in the E-mail configuration section? This is only to generate the links in emails Jenkins sends (see the help for the option -- click the symbol with the question mark). If after changing it you cannot access your server anymore, it must be something else.