Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-38520

Every message in agent log appears twice with the -agentLog option

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • remoting
    • 3148.v532a_7e715ee3 , 2.426.1

      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).

          [JENKINS-38520] Every message in agent log appears twice with the -agentLog option

          Matěj Korvas created issue -
          Matěj Korvas made changes -
          Environment Original: * Virtualbox 64-bit Ubuntu
          * Java 7, Oracle:
          {noformat}
          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)
          {noformat}
          * Jenkins installed and run as described in [Building Jenkins|https://wiki.jenkins-ci.org/display/JENKINS/Building+Jenkins], except I checked out the LTS version tag 2.7.4 (remoting v2.60)
          New: * 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 [Building Jenkins|https://wiki.jenkins-ci.org/display/JENKINS/Building+Jenkins], except I checked out the LTS version tag 2.7.4 (remoting v2.60)
          Matěj Korvas made changes -
          Environment Original: * 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 [Building Jenkins|https://wiki.jenkins-ci.org/display/JENKINS/Building+Jenkins], except I checked out the LTS version tag 2.7.4 (remoting v2.60)
          New: * 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)
          Daniel Beck made changes -
          Component/s New: remoting [ 15489 ]
          Component/s Original: core [ 15593 ]
          Matěj Korvas made changes -
          Description Original: 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:
          {noformat}
          channel startedchannel started

          channel stoppedchannel stopped

          {noformat}
          (which is not expected).

          The launch script looks as follows ({{/home/matej/wc/jenkins}} is path to the Jenkins clone):
          {noformat}
          #!/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"
          {noformat}

          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). In our production Jenkins environment, we start slaves using a similar command and we see them fail to start more often than succeed, which could point to some concurrency issues.
          New: 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:
          {noformat}
          channel startedchannel started

          channel stoppedchannel stopped

          {noformat}
          (which is not expected).

          The launch script looks as follows ({{/home/matej/wc/jenkins}} is path to the Jenkins clone):
          {noformat}
          #!/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"
          {noformat}

          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).

          Matěj Korvas added a comment -

          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.

          Matěj Korvas added a comment - 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.
          Oleg Nenashev made changes -
          Summary Original: Every message in slave log appears twice New: Every message in slave log appears twice with the -slaveLog option

          Oleg Nenashev added a comment -

          slaveLog redirects only the STDERR stream, so it should not happen. In the original request the example shows two different messages. Will check if it happens on my instance

          Oleg Nenashev added a comment - slaveLog redirects only the STDERR stream, so it should not happen. In the original request the example shows two different messages. Will check if it happens on my instance

          Oleg Nenashev added a comment -

          JENKINS-39369 should solve this issue as well by providing a better log management option

          Oleg Nenashev added a comment - JENKINS-39369 should solve this issue as well by providing a better log management option
          Oleg Nenashev made changes -
          Link New: This issue is related to JENKINS-39369 [ JENKINS-39369 ]

            basil Basil Crow
            mkorvas Matěj Korvas
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: