jenkinsci / docker-agent Goto Github PK
View Code? Open in Web Editor NEWJenkins agent (base image) and inbound agent Docker images
Home Page: https://hub.docker.com/r/jenkins/inbound-agent/
License: MIT License
Jenkins agent (base image) and inbound agent Docker images
Home Page: https://hub.docker.com/r/jenkins/inbound-agent/
License: MIT License
Hey guys,
First, thanks a lot for maintaining this repo.
Can you please consider releasing a new version?
Now, when I want to use a version later than 2.62 of this Docker image, I have to use 'latest' - and it's very very not convenient...
Thanks,
I've got a complete showstopper.
I'm trying to get Jenkins to control our testing hosts, which work as follows:
1 - when idle, the test host is running Linux (with the SSH-controlled agent running).
2 - when a test is started and the agent has fired off all the required scripts, the host boots into FreeDOS and runs things for a while (up to a few days or more). FreeDOS has NO networking installed, so that even if there was a Jenkins hook for DOS we'd be out of luck. Anyway, Jenkins obviously decides the agent is offline, but ...
3 - when the FreeDOS part of the test is finished and the test host reboots in to Linux Jenkins appears to never try to relaunch the agent. So far, the ONLY way to get Jenkins back to talking to it is to manually 'Launch agent' from the 'Jenkins -> Nodes -> ' page. Since you must be logged in for the 'launch agent' button to be visible, I'm not expecting to have much luck writing a script to force Jenkins to Launch the agent.
The agents are all configured as follows:
Launch Method: Launch slave agents via ssh
Maximum number of retries: 0
Seconds to wait between retries: 30 (have tried 0 also)
Availability: Keep this agent online as much as possible.
I've tried searching all over the place, and I've even hit up the Jira, and the only thing that has happened there is someone took the component that I guessed it might be off the list, without giving me any kind of hint as to what I should put on it (JENKINS-47327, if you want to go look there, as I have the systeminfo.pdf and the pipeline script I'm running included there).
I need to either figure out how to get Jenkins to start the agent like I thought it was supposed to, OR find a hook or something I can use to relaunch the agent from a script. Or maybe someone can fix it, but right now, I'll just settle for a hack to make it work.
I'm new to Jenkins and trying to troubleshoot an issue where our Jenkins agent fails to start. Error: Error: Could not find or load main class hudson.remoting.jnlp.Main
We are running:
Jenkins master version: 2.22
Jenkins jnlp slave version: 2.90
Any idea why my agents stopped working? The only change i did is upgrade from 2.20 to 2.22
Base Doker image for Jenkins Agents
Hello, I'm trying to use this (jenkinsci/jnlp-slave from Docker hub) with what I have to imagine is the simplest "dip a toe in the water" setup and I'm failing.
I was hoping someone could set me straight as what I am experiencing does not seem to be a failure of the Docker Plugin itself.
testdocker
and image jenkinsci/jnlp-slave
. All else left at defaults.testdocker
. One build step: Execute echo hi
in a shell....
Oct 19 20:13:28 etc-jenkins-docker dockerd-current[38386]: time="2017-10-19T20:13:28.137871745-04:00" level=debug msg="Calling POST /containers/create"
Oct 19 20:13:28 etc-jenkins-docker dockerd-current[38386]: time="2017-10-19T20:13:28.137967444-04:00" level=debug msg="form data: {\"Cmd\":[\"java\",\"-cp\",\"/home/jenkins/remoting-3.10.2.jar\",\"hudson.remoting.jnlp.Main\",\"-headless\",\"-url\",\"https://jenkins-dev.our.org/\",\"ae9d3776445a6d054ab5e870521d54029f2e2b0f11a76a3e236b6fafbdecc099\",\"Docker-1cefd70467447a\"],\"ExposedPorts\":{},\"HostConfig\":{\"PortBindings\":{},\"Privileged\":false,\"PublishAllPorts\":false},\"Image\":\"jenkinsci/jnlp-slave\",\"Labels\":{\"JenkinsId\":\"319f62f30dccb87c8a4f8fa7a272a77b\"},\"Tty\":false,\"Volumes\":{}}"
...
Oct 19 20:13:29 etc-jenkins-docker dockerd-current[38386]: "-cp" is not a valid option
Oct 19 20:13:29 etc-jenkins-docker dockerd-current[38386]: java -jar slave.jar [options...] <secret key> <slave name>
Oct 19 20:13:29 etc-jenkins-docker dockerd-current[38386]: -agentLog FILE : Local agent error log destination (overrides
Oct 19 20:13:29 etc-jenkins-docker dockerd-current[38386]: workDir)
...
Oct 19 20:13:29 etc-jenkins-docker dockerd-current[38386]: time="2017-10-19T20:13:29.598265848-04:00" level=debug msg="libcontainerd: received containerd event: &types.Event{Type:\"exit\", Id:\"ca46783418d1763cef3ed279c8c1d26a5704348aef1a342ac40c6731fc6a5c2d\", Status:0x0, Pid:\"init\", Timestamp:(*timestamp.Timestamp)(0xc421718a10)}"
Oct 19 20:13:29 etc-jenkins-docker dockerd-current[38386]: time="2017-10-19T20:13:29.598467018-04:00" level=debug msg="attach: stdout: end"
Oct 19 20:13:29 etc-jenkins-docker dockerd-current[38386]: time="2017-10-19T20:13:29.598484170-04:00" level=debug msg="attach: stderr: end"
...
Hi,
Is it really necessary to mark the jenkins user home dir as a VOLUME in the Dockerfile? If not, I would prefer it to be something I can do in my own deriving image. Right now this is blocking me from chowning and chmodding files that I COPY into the home dir (like ssh keys) in my own Dockerfile. Since the VOLUME comes before, such changes are discarded.
When running a Jenkins slave (jenkinsci/jnlp-slave) as a container on ECS, the task stops immediately. The logs show the following:
two arguments required, but got []
java -jar slave.jar [options...]
-cert VAL : Specify additional X.509 encoded PEM
certificates to trust when connecting to
Jenkins root URLs. If starting with @ then
the remainder is assumed to be the name of
the certificate file to read.
-credentials USER:PASSWORD : HTTP BASIC AUTH header to pass in for making
HTTP requests.
-headless : Run in headless mode, without GUI
-jar-cache DIR : Cache directory that stores jar files sent
from the master
-noreconnect : If the connection ends, don't retry and just
exit.
-proxyCredentials USER:PASSWORD : HTTP BASIC AUTH header to pass in for making
HTTP authenticated proxy requests.
-tunnel HOST:PORT : Connect to the specified host and port,
instead of connecting directly to Jenkins.
Useful when connection to Hudson needs to be
tunneled. Can be also HOST: or :PORT, in
which case the missing portion will be
auto-configured like the default behavior
-url URL : Specify the Jenkins root URLs to connect to.
I have the URL listed as an environment variable with the URL of the Jenkins master as its value. Do I need to specify the url in the entrypoint?
Hi,
This is my first time to use dockerize jenkins jnlp-slave I tried the following command:
sudo docker run jenkinsci/jnlp-slave -url http://localhost:8080 secretkey slavename
and it shows something like this:
Jun 10, 2016 7:54:22 AM hudson.remoting.jnlp.Main createEngine INFO: Setting up slave: slavename Jun 10, 2016 7:54:22 AM hudson.remoting.jnlp.Main$CuiListener <init> INFO: Jenkins agent is running in headless mode. Jun 10, 2016 7:54:22 AM hudson.remoting.jnlp.Main$CuiListener status INFO: Locating server among [http://localhost:8080] Jun 10, 2016 7:54:23 AM hudson.remoting.jnlp.Main$CuiListener error SEVERE: Failed to connect to http://localhost:8080/tcpSlaveAgentListener/: No route to host java.io.IOException: Failed to connect to http://localhost:8080/tcpSlaveAgentListener/: No route to host at hudson.remoting.Engine.run(Engine.java:208) Caused by: java.net.NoRouteToHostException: No route to host at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at sun.net.NetworkClient.doConnect(NetworkClient.java:175) at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) at sun.net.www.http.HttpClient.<init>(HttpClient.java:211) at sun.net.www.http.HttpClient.New(HttpClient.java:308) at sun.net.www.http.HttpClient.New(HttpClient.java:326) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1168) at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1104) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:998) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:932) at hudson.remoting.Engine.run(Engine.java:205)
http://localhost:8080 is where my jenkins is running. Did I miss some configuration?
We are running the 3.19-1-alpine version and after the jenkins upgrade from 2.134 to 2.135 our builds started failing with this message:
Running shell script
ps: unrecognized option: p
BusyBox v1.27.2 (2018-06-06 09:08:44 UTC) multi-call binary.
Usage: ps [-o COL1,COL2=HEADER]
Show list of processes
-o COL1,COL2=HEADER Select columns for display
Adding apk add procps
to the jnlp-slave image fixed the issue. Maybe this should be part of the published image?
I couldn't find the place where ps -p
is called, though. It might also be in one of the plugins, like jenkins-kubernetes.
I was planning to use this image as my base image but I found some ugly errors using curl
:
[0] ~ >> docker run -it --rm --entrypoint /bin/bash --user root jenkins/jnlp-slave:3.10-1-alpine
bash-4.3# apk add -U curl
fetch http://dl-cdn.alpinelinux.org/alpine/v3.6/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.6/community/x86_64/APKINDEX.tar.gz
(1/1) Installing curl (7.56.1-r0)
Executing busybox-1.26.2-r5.trigger
OK: 134 MiB in 67 packages
bash-4.3# curl
Error relocating /usr/bin/curl: curl_mime_data_cb: symbol not found
Error relocating /usr/bin/curl: curl_mime_name: symbol not found
Error relocating /usr/bin/curl: curl_mime_encoder: symbol not found
Error relocating /usr/bin/curl: curl_mime_init: symbol not found
Error relocating /usr/bin/curl: curl_mime_headers: symbol not found
Error relocating /usr/bin/curl: curl_mime_filedata: symbol not found
Error relocating /usr/bin/curl: curl_mime_free: symbol not found
Error relocating /usr/bin/curl: curl_mime_subparts: symbol not found
Error relocating /usr/bin/curl: curl_mime_type: symbol not found
Error relocating /usr/bin/curl: curl_mime_addpart: symbol not found
Error relocating /usr/bin/curl: curl_mime_filename: symbol not found
Error relocating /usr/bin/curl: curl_mime_data: symbol not found
bash-4.3#
Where is the Dockerfile for jenkins/jnlp-slave:3.10-1-alpine
?
Hello,Could you tell me docker jenkinsci/jnlp-slave image root password?Thanks~3Q,I need it~~
I'm trying to build customized JNLP Jenkins Containers for various processes which need to install additional packages. Having the USER ${user} switches the current user over to an unprivileged jenkins user which doesn't allow for package installation.
This is not an issue with the ssh-slave docker container because it is not utilizing this as an upstream.
jenkinsci/jenkins creates jenkins
user with: gid=1000
and uid=1000
. Jenkins slave declares user with uid=10000
. jenkins:jnlp-slave
creates user with adduser -S -h $HOME jenkins jenkins
All these makes difficult to reuse artifacts generated by job executed on master (like checkout
step) by slave that operates with different uid/gid and shares the same workspace.
I would like to propose move migrate slaves under unified user jenkins:jenkins
with same uid
and gid
Currently the releases are being done to jenkins/slave
and jenkinsci/slave
, but there is an interest to have a more orchestrated release flow for new Remoting versions, probably with image signing
My jenkin server is using 40002 as slave port but the slave container tries to connect to 50000. How to pass this option?
Hi Team,
I am trying to run docker commands and aws cli scripts in my ecs slave nodes but by default it is not configured. Can someone suggest how to achieve this.
--raja
I've set up a Jenkins master on GKE along with the Kubernetes plugin however, I keep hitting a java.io.IOException: Failed to write to /home/jenkins/.jenkins/cache/jars/F2/84FCC8C54FBFD68EF9E319A863DC13.jar
error whenever a new slave is created by the plugin.
Using the image jenkinsci/jnlp-slave
with an Always pull
setting.
Master image is jenkinsci/jenkins:2.46.1-alpine
I've tried setting _JAVA_OPTIONS
to -Duser.home=/tmp
, unsuccessfully.
Any help is appreciated.
PS: I've ran into #728 , which I worked around by unsetting both JENKINS_NAME
and JENKINS_SECRET
and passing ${computer.jnlpmac} ${computer.name}
as build args to the slave.
ARG uid=10000
ARG gid=10000
Not 1000, like the uid jenkins in the docker image jenkins/jenkins ?
When I run the slave as I always used to do it (using Kubernetes plugin) - it passes these arguments to the command:
${computer.jnlpmac} ${computer.name}
Now, using the latest jnlp-slave version, I get this error:
two arguments required, but got [${computer.jnlpmac}, ${computer.name},${computer.jnlpmac}, ${computer.name}]
(the arguments are doubled)
Current workaround that solves it:
I explicitly set JENKINS_SECRET and JENKINS_NAME environment variables to be empty.
version: '2'
services:
jenkinsci-slave5:
image: jenkinsci/jnlp-slave
environment:
JENKINS_AGENT_NAME: jenkins-slave
JENKINS_SECRET: fac1f848bf46d90440979a3e9914f5e412b49b7ebf1fe0adc4bfa2ad2fcd349b
JENKINS_URL: master
volumes:
- /home/jenkins/slave-1-home:/home/jenkins
- /home/jenkins/m2/repository:/home/.m2/repository
stdin_open: true
tty: true
labels:
io.rancher.container.pull_image: alway
We are want keep the data to the same place.
But it's got exception when we mount volume on it.
Hello,
When running multiple sh commands within a pipeline, I am receiving multiple defunct sh and sleep processes, if the job runs within a jenkins/jnlp-slave:latest docker container.
The master is running on the same host using jenkins/jenkins:lts-alpine and if the jobs runs on the master, I cannot find any defunct processes.
The simplest pipeline to reproduce the problem may be:
node() {
stage ('Run Tests') {
sh 'echo "hello world"'
}
stage ('Run Tests2') {
sh 'echo "hello world"'
}
}
And after running the job list the defunct proccesses on the host:
$ ps aux | grep defunct | grep -v grep
10000 8054 0.0 0.0 0 0 ? Z 16:34 0:00 [sh] <defunct>
10000 8057 0.0 0.0 0 0 ? Z 16:34 0:00 [sleep] <defunct>
I'm running a Jenkins master version 2.67 on ubuntu and attempting to set up an agent using this image on a separate physical machine (also ubuntu).
This image requires a secret, but I cannot find any documentation to say where to find this secret. As a result, I'm unable to start this image.
Any help here would be very much appreciated.
{
"name": "jnlp-slave",
"state": {
"terminated": {
"exitCode": 127,
"reason": "Error",
"startedAt": "2017-11-23T12:53:13Z",
"finishedAt": "2017-11-23T12:53:13Z",
"containerID": "docker://d24c4181c514913ff4db68eac901871af3b300ea218a32549a99c272ebebb933"
}
},
"lastState": {},
"ready": false,
"restartCount": 0,
"image": "docker.io/jenkins/jnlp-slave:latest",
"imageID": "docker-pullable://docker.io/jenkins/jnlp-slave@sha256:d73576772018c593de90ceb755fa34c4f135d7fb4fc2e111a0a4f8f814d4c2a5",
"containerID": "docker://d24c4181c514913ff4db68eac901871af3b300ea218a32549a99c272ebebb933"
}
We used the jenkins-kubernetes plugin to set up a test framework, and we found that the jnlp-container in each jenkins slave consumes about 200M memories. Is it normal or there is something wrong?
Is there any way to constrain the memory consumption? Will such limit affects the performance?
Could you update the Alpine version with the new version of Alpine?
This because of this security problem: https://justi.cz/security/2018/09/13/alpine-apk-rce.html
This docker image is deprecated? or released artifact in github is deprecated?
Please be more specific in the README.md
Hi, everyone!
Assuming I use this exact image I only get an environment with JDK, right? What if I want to build other types of projects? Or more specifically, when configuring the image for the slave I cannot have multiple images and configure the pipeline to use a specific slave.
So what is the accepted way of building multiple types of projects, considering the following:
The obvious way to handle this is to have Docker inside the slave, as described in this article and mount /var/run/docker.sock
into the container.
I did this and you can find the resulting Dockerfile here (I also put kubectl
), GitHub repo here.
The question I have is: apart from this method, is there any other that allows me to build whatever project I want without modifying the slave?
Thanks,
Radu M
ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins.
java.lang.RuntimeException: Root directory not writable: /home/jenkins/.jenkins/cache/jars
at hudson.remoting.FileSystemJarCache.(FileSystemJarCache.java:57)
at hudson.remoting.JarCache.getDefault(JarCache.java:32)
at hudson.remoting.Channel.(Channel.java:520)
at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:323)
at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:389)
at hudson.plugins.sshslaves.SSHLauncher.startSlave(SSHLauncher.java:1074)
at hudson.plugins.sshslaves.SSHLauncher.access$500(SSHLauncher.java:145)
at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:818)
at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:793)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
[09/12/17 10:15:09] Launch failed - cleaning up connection
[09/12/17 10:15:09] [SSH] Connection closed.
Please post or link to instructions on what configuration is required on the Jenkins server to submit jobs through JNLP to a slave running on a remote UNIX host. Is a .jnlp file required? If so, what elements are required in the JNLP file?
Hi.
I'm trying to build agents for testing my project on different os platforms (Ubuntu, RH etc) using Jenkins JNLP Agent Docker image.
To do so I want to built a container for each os platform that runs Jenkins JNLP Agent. Thus I need to create a dockerfile for each os, that also runs JNLP Agent on top of it.
Since Jenkins JNLP Agent dockerfile contains the COPY cmd, I can't combine two dockerfiles (e.g ubuntu & JNLP Agent dockerfiles).
Any suggestions how to do that?
Could you be kind to publish a more robust dockerfile for JNLP Agent?
Many thanks
Container-Optimized OS (cos) - GKE kubernetes 1.5.6 works fine
Container-Optimized OS (cos) - GKE kubernetes 1.6.6 fails with the following error.
docker: error while loading shared libraries: libapparmor.so.1: cannot open shared object file: No such file or directory
I don't see a way to open an issue with https://github.com/jenkinsci/kubernetes-plugin
Any help or guidance would be appreciated.
The ssh package (openssh?) seems to be missing in the alpine edition of the jnlp-slave (jenkinsci/jnlp-slave:alpine).
Thus I am not able to do a "checkout scm" from a private github repo secured by ssh access.
Error Message: stderr: /tmp/ssh2342644730406476600.sh: line 6: ssh: not found
Current workaround: Use of jenkinsci/jnlp-slave instead of jenkinsci/jnlp-slave:alpine
See also: https://issues.jenkins-ci.org/browse/JENKINS-41137
Hi,
I try to use this container via Jenkins kubernetes-plugin and faced with issus that i have not root access to install directly what i need.
How can i overcome it? Because i wont use this container as base.
Like JENKINS_URL
it should be possible to specify SLAVE_SECRET
and SLAVE_NAME
. This should make it easier to provision slave templates and avoid mistakes with entrypoint and command.
I am running Docker version 17.06.0-ce, build 02c1d87
on macOS Sierra 10.12.3
. When I am building this image from the Dockerfile
I run into:
DN0a22f10f:jenkins_slave otto$ docker build -t jenkins_slave .
Sending build context to Docker daemon 2.048kB
Step 1/3 : FROM jenkinsci/slave
latest: Pulling from jenkinsci/slave
ef0380f84d05: Already exists
24c170465c65: Already exists
4f38f9d5c3c0: Already exists
1cbb987bd399: Already exists
d1d084a70984: Already exists
09373cf6f1c7: Already exists
f5d486a02fa0: Already exists
3e979ba42b15: Already exists
594e48fef5be: Already exists
474c368fdccb: Pull complete
9da87a67ea1c: Pull complete
49cc2ac91501: Pull complete
99318043b588: Pull complete
Digest: sha256:73ac717ad9b9694ff658af3824b54ee0dcbc64b7319db37897489349rl77gl3l5k
Status: Downloaded newer image for jenkinsci/slave:latest
---> 128251074396
Step 2/3 : COPY jenkins-slave /usr/local/bin/jenkins-slave
COPY failed: stat /var/lib/docker/tmp/docker-builder912747621/jenkins-slave: no such file or
directory
Would anyone have idea what is the reason of this issue?
Trying to run a master and a agent with the following docker-compose.yml:
version: "2.2"
services:
master:
image: jenkins/jenkins:alpine
ports:
- 8080:8080
volumes:
- ./jenkins_home:/var/jenkins_home
slave:
image: jenkins/slave:alpine
command: ["java", "-jar", "/usr/share/jenkins/slave.jar"]
init: true
But I get this error:
Exception in thread "main" java.io.EOFException: unexpected stream termination
at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:378)
at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:323)
at hudson.remoting.Launcher.main(Launcher.java:742)
at hudson.remoting.Launcher.runWithStdinStdout(Launcher.java:680)
at hudson.remoting.Launcher.run(Launcher.java:362)
at hudson.remoting.Launcher.main(Launcher.java:277)
<===[JENKINS REMOTING CAPACITY]===>rO0ABXNyABpodWRzb24ucmVtb3RpbmcuQ2FwYWJpbGl0eQAAAAAAAAABAgABSgAEbWFza3hwAAAAAAAAAP4=
Docker images should be updated to reflect this.
JENKINS-35451
Currently the version is 2.52 and the last released version is 2.59
http://repo.jenkins-ci.org/public/org/jenkins-ci/main/remoting
Hello everyone,
I tried to use the automatic Slave deployment with my Kubernetes cluster and my Jenkins Master, but i face a problem when the Slave is provisioning :
Here the logs of the pod :
2016-09-05T11:54:31.771124775Z Warning: JnlpProtocol3 is disabled by default, use JNLP_PROTOCOL_OPTS to alter the behavior
2016-09-05T11:54:31.972612022Z Sep 05, 2016 11:54:31 AM hudson.remoting.jnlp.Main createEngine
2016-09-05T11:54:31.972635623Z INFO: Setting up slave: jnlp-slave-a7265a22a0820
2016-09-05T11:54:31.974522204Z Sep 05, 2016 11:54:31 AM hudson.remoting.jnlp.Main$CuiListener <init>
2016-09-05T11:54:31.974535404Z INFO: Jenkins agent is running in headless mode.
2016-09-05T11:54:31.984373826Z Exception in thread "main" java.lang.RuntimeException: Root directory not writable
2016-09-05T11:54:31.984453230Z at hudson.remoting.FileSystemJarCache.<init>(FileSystemJarCache.java:44)
2016-09-05T11:54:31.984472631Z at hudson.remoting.Engine.<init>(Engine.java:139)
2016-09-05T11:54:31.984497832Z at hudson.remoting.jnlp.Main.createEngine(Main.java:164)
2016-09-05T11:54:31.984520933Z at hudson.remoting.jnlp.Main.main(Main.java:148)
2016-09-05T11:54:31.984544634Z at hudson.remoting.jnlp.Main._main(Main.java:144)
2016-09-05T11:54:31.984568535Z at hudson.remoting.jnlp.Main.main(Main.java:110)
I tried with the slaves in Privileged mode = true and some other stuff but still not working, if someone have an idea :)
Théo
I am currently experiencing this issue: http://stackoverflow.com/questions/41253094/kubernetes-plugin-containers-cant-connect-back-to-jenkins
Can you guys point me in the right direction?
I am using this image within a Kubernetes pod to control a slave as this is the default container for such Jenkins slaves.
Checking out some Git repository using Git LFS within a declarative pipeline fails due to missing git-lfs binary.
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository [email protected]:git-lfs-test.git
> /usr/bin/git init /var/lib/jenkins/workspace/kins_git-lfs-test_jenkins-EHEFW2M6YTSZSXCQN2C55M5ZSQFEMFT5ZOBC23X4WFGL7NLBKIIQ # timeout=10
Fetching upstream changes from [email protected]:git-lfs-test.git
> /usr/bin/git --version # timeout=10
using GIT_SSH to set credentials Local private SSH key of the Jenkins master server
> /usr/bin/git fetch --no-tags --progress [email protected]:git-lfs-test.git +refs/heads/*:refs/remotes/origin/*
> /usr/bin/git config remote.origin.url [email protected]:git-lfs-test.git # timeout=10
> /usr/bin/git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
> /usr/bin/git config remote.origin.url [email protected]:git-lfs-test.git # timeout=10
Fetching without tags
Fetching upstream changes from [email protected]:git-lfs-test.git
using GIT_SSH to set credentials Local private SSH key of the Jenkins master server
> /usr/bin/git fetch --no-tags --progress [email protected]:git-lfs-test.git +refs/heads/*:refs/remotes/origin/*
Checking out Revision 4eabb26d3e524942d8dc7599236e796dfc45f8cc (jenkins)
Enabling Git LFS pull
> /usr/bin/git config core.sparsecheckout # timeout=10
> /usr/bin/git checkout -f 4eabb26d3e524942d8dc7599236e796dfc45f8cc
> /usr/bin/git config --get remote.origin.url # timeout=10
using GIT_SSH to set credentials Local private SSH key of the Jenkins master server
> /usr/bin/git lfs pull origin
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
hudson.plugins.git.GitException: Command "/usr/bin/git lfs pull origin" returned status code 1:
stdout:
stderr: git: 'lfs' is not a git command. See 'git --help'.
Did you mean this?
log
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1996)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1715)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:72)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:2307)
Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to Slave2
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741)
at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:955)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor573.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy103.execute(Unknown Source)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1210)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:113)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:85)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:75)
at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47)
at hudson.security.ACL.impersonate(ACL.java:290)
at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
Caused: hudson.plugins.git.GitException: Could not checkout 4eabb26d3e524942d8dc7599236e796dfc45f8cc
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:2319)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Finished: FAILURE
See https://issues.jenkins-ci.org/browse/JENKINS-44104
There was an attempt to do it in jenkinsci/docker-inbound-agent#19, but it was rejected. This update should be optional.
Just to note the proposal by @dduportal in #4 (comment)
LTS currently uses remoting 3.13, any chance we could get a container for that version?
Our Jenkins server uses a self signed certificate and the docker image is refusing to connect. I've added "-noCertificateCheck" to the JVM arguments field in the system configuration of the Amazon EC2 container service plug-in but it does not seem to be getting used by the container. How should I be passing this option to the container?
if i want pass JVM options when creating slave node on jenkins master ?
Looking on docker hub I was wondering why the home directory on the jenkinsci/jnlp-slave
image was a volume instead of /home/jenkins/.jenkins
. I looked into it and it seems the current image on docker hub is using an older version of jenkinsci/slave
.
It appears that jenkinsci/slave
was updated roughly 30 minutes after jenkins/jnlp-slave
. This caused jenkins/jnlp-slave to not receive the updates from jenkinsci/slave
https://hub.docker.com/r/jenkinsci/jnlp-slave/builds/bbiwdakzwehkc7vvtuhpbaw/
https://hub.docker.com/r/jenkinsci/slave/builds/bnkls23k5zz4tmwaykdqap6/
I'm trying to connect a Docker container to an existing Jenkins instance via JNLP
This command works:
docker run jenkins/jnlp-slave -url https://myjenkins.com 123456789abcdef myagent
This command does not work:
docker run -e JENKINS_SECRET=123456789abcdef -e JENKINS_AGENT_NAME=myagent -e JENKINS_URL=https://myjenkins.com jenkins/jnlp-slave
I've also hard coded the environment variables to a Dockerfile and built an image. Same error.
No changes to the Jenkins master between the different commands.
Why does JNLP4 behave differently via docker run and environment variables?
Feb 27, 2018 6:27:40 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Agent discovery successful
Agent address: myjenkins.com
Agent port: 50000
Identity: 7f:a8:7f:ae:7b:7f:2d:f8:e9:b9:53:48:33:6c:0e:c6
Feb 27, 2018 6:27:40 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Handshaking
Feb 27, 2018 6:27:40 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Connecting to myjenkins.com:50000
Feb 27, 2018 6:27:40 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Trying protocol: JNLP4-connect
Feb 27, 2018 6:27:40 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Remote identity confirmed: 7f:a8:7f:ae:7b:7f:2d:f8:e9:b9:53:48:33:6c:0e:c6
Feb 27, 2018 6:27:41 PM org.jenkinsci.remoting.protocol.impl.ConnectionHeadersFilterLayer onRecv
INFO: [JNLP4-connect connection to myjenkins.com/10.10.2.193:50000] Local headers refused by remote: Authorization failure
Feb 27, 2018 6:27:41 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Protocol JNLP4-connect encountered an unexpected exception
java.util.concurrent.ExecutionException: org.jenkinsci.remoting.protocol.impl.ConnectionRefusalException: Authorization failure
at org.jenkinsci.remoting.util.SettableFuture.get(SettableFuture.java:223)
at hudson.remoting.Engine.innerRun(Engine.java:609)
at hudson.remoting.Engine.run(Engine.java:469)
Caused by: org.jenkinsci.remoting.protocol.impl.ConnectionRefusalException: Authorization failure
at org.jenkinsci.remoting.protocol.impl.ConnectionHeadersFilterLayer.newAbortCause(ConnectionHeadersFilterLayer.java:378)
at org.jenkinsci.remoting.protocol.impl.ConnectionHeadersFilterLayer.onRecvClosed(ConnectionHeadersFilterLayer.java:433)
at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.onRecvClosed(ProtocolStack.java:832)
at org.jenkinsci.remoting.protocol.FilterLayer.onRecvClosed(FilterLayer.java:287)
at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.onRecvClosed(SSLEngineFilterLayer.java:172)
at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.onRecvClosed(ProtocolStack.java:832)
at org.jenkinsci.remoting.protocol.NetworkLayer.onRecvClosed(NetworkLayer.java:154)
at org.jenkinsci.remoting.protocol.impl.BIONetworkLayer.access$1500(BIONetworkLayer.java:48)
at org.jenkinsci.remoting.protocol.impl.BIONetworkLayer$Reader.run(BIONetworkLayer.java:247)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at hudson.remoting.Engine$1$1.run(Engine.java:94)
at java.lang.Thread.run(Thread.java:748)
Suppressed: java.nio.channels.ClosedChannelException
... 7 more
Feb 27, 2018 6:27:41 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Connecting to myjenkins.com:50000
Feb 27, 2018 6:27:41 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Server reports protocol JNLP4-plaintext not supported, skipping
Feb 27, 2018 6:27:41 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Protocol JNLP3-connect is not enabled, skipping
Feb 27, 2018 6:27:41 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Server reports protocol JNLP2-connect not supported, skipping
Feb 27, 2018 6:27:41 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Server reports protocol JNLP-connect not supported, skipping
Feb 27, 2018 6:27:41 PM hudson.remoting.jnlp.Main$CuiListener error
SEVERE: The server rejected the connection: None of the protocols were accepted
java.lang.Exception: The server rejected the connection: None of the protocols were accepted
at hudson.remoting.Engine.onConnectionRejected(Engine.java:670)
at hudson.remoting.Engine.innerRun(Engine.java:634)
at hudson.remoting.Engine.run(Engine.java:469)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.