Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Minor
-
Resolution: Cannot Reproduce
-
Component/s: remoting
-
Labels:
-
Environment:* Virtualbox 64-bit Ubuntu
* Java 7, Oracle:
java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
* Jenkins installed and run as described in https://wiki.jenkins-ci.org/display/JENKINS/Building+Jenkins, except I checked out the LTS version tag 2.7.4 (remoting v2.60)* Virtualbox 64-bit Ubuntu * Java 7, Oracle: java version "1.7.0_80" Java(TM) SE Runtime Environment (build 1.7.0_80-b15) Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode) * Jenkins installed and run as described in https://wiki.jenkins-ci.org/display/JENKINS/Building+Jenkins, except I checked out the LTS version tag 2.7.4 (remoting v2.60)
-
Similar Issues:
Description
Running a local slave, launched using a command, with the -slaveLog option causes a log file to be written (as expected) with every message printed twice there, like this:
channel startedchannel started channel stoppedchannel stopped
(which is not expected).
The launch script looks as follows (/home/matej/wc/jenkins is path to the Jenkins clone):
#!/bin/bash --norc export TMP=$(mktemp -d --tmpdir jenkins-XXXXX) SLAVEJAR_URL=http://localhost:8080/jenkins/jnlpJars/slave.jar wget -q "${SLAVEJAR_URL:?}" -P "${TMP:?}" 2>&1 _log_dir=/home/matej/wc/jenkins/work/logs mkdir -p "$_log_dir" _log=$(mktemp -u "$_log_dir/$(date -u +%Y%m%d-%H%M%S)-XXX") export JAVA_HOME=/usr/lib/jvm/java-7-oracle "$JAVA_HOME"/bin/java -jar "$TMP"/slave.jar \ -slaveLog "$_log"
I wondered whether it is just the messages that gets duplicated (perhaps caused by the TeeOutputStream created by the Launcher effectively outputting twice to the identical output stream) or if it is the threads calling Launcher.run() (I cannot imagine how that could happen).
Attachments
Issue Links
- is related to
-
JENKINS-39369 Automatically dump agent logs to the disk
-
- Resolved
-
I have removed the note about potentially related issue of slaves failing to start. It turned out to be solvable by using the -text argument to slave.jar, while messages continue to be printed twice in slave logs.