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

Cannot run program "/bin/java" on maven 3 projects

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • maven-plugin
    • None
    • 1.580, Ubuntu 12.04 LTS 64

      We've had this issue for a while, mostly after a slave is started where the maven command insist on using /bin/java. We do not have a /bin/java since we want to control the version of Java on a per job basis, so adding it is not an option.

      00:00:06.627 Parsing POMs
      00:00:07.322 maven3-agent.jar already up to date
      00:00:07.331 maven3-interceptor.jar already up to date
      00:00:07.341 maven3-interceptor-commons.jar already up to date
      00:00:07.347 [build-shnproxy-trunk] $ /bin/java -Xmx6000m -XX:MaxPermSize=2000m -cp /shn/builder/maven3-agent.jar:/shn/builder/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5/boot/plexus-classworlds-2.4.jar org.jvnet.hudson.maven3.agent.Maven3Main /shn/builder/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5 /shn/builder/slave.jar /shn/builder/maven3-interceptor.jar /shn/builder/maven3-interceptor-commons.jar 33037
      00:00:07.353 ERROR: Failed to parse POMs
      00:00:07.353 java.io.IOException: Cannot run program "/bin/java" (in directory "/shn/builder/workspace/build-shnproxy-trunk"): java.io.IOException: error=2, No such file or directory
      00:00:07.353 	at java.lang.ProcessBuilder.start(ProcessBuilder.java:460)
      00:00:07.353 	at hudson.Proc$LocalProc.<init>(Proc.java:244)
      00:00:07.353 	at hudson.Proc$LocalProc.<init>(Proc.java:216)
      00:00:07.353 	at hudson.Launcher$LocalLauncher.launch(Launcher.java:802)
      00:00:07.353 	at hudson.Launcher$ProcStarter.start(Launcher.java:380)
      00:00:07.353 	at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1135)
      00:00:07.353 	at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1100)
      00:00:07.353 	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
      00:00:07.353 	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
      00:00:07.353 	at hudson.remoting.Request$2.run(Request.java:328)
      00:00:07.353 	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
      00:00:07.353 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
      00:00:07.353 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
      00:00:07.353 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
      00:00:07.353 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
      00:00:07.353 	at java.lang.Thread.run(Thread.java:662)
      00:00:07.353 Caused by: java.io.IOException: java.io.IOException: error=2, No such file or directory
      00:00:07.353 	at java.lang.UNIXProcess.<init>(UNIXProcess.java:148)
      00:00:07.353 	at java.lang.ProcessImpl.start(ProcessImpl.java:65)
      00:00:07.353 	at java.lang.ProcessBuilder.start(ProcessBuilder.java:453)
      00:00:07.353 	... 15 more

      Usually after a few failed builds the slave gets the correct version of java and works:

      Parsing POMs
      maven3-agent.jar already up to date
      maven3-interceptor.jar already up to date
      maven3-interceptor-commons.jar already up to date
      [build-shnproxy-trunk] $ /shn/builder/tools/hudson.model.JDK/JDK7/jdk1.7.0_51/bin/java -Xmx6000m -XX:MaxPermSize=2000m -cp /shn/builder/maven3-agent.jar:/shn/builder/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5/boot/plexus-classworlds-2.4.jar org.jvnet.hudson.maven3.agent.Maven3Main /shn/builder/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5 /shn/builder/slave.jar /shn/builder/maven3-interceptor.jar /shn/builder/maven3-interceptor-commons.jar 58912
      <===[JENKINS REMOTING CAPACITY]===>���channel started
      

      This time it has been stuck for 2 jobs for the past 2 days, with no end in sight. I can't figure out why it keeps on pointing to /bin/java

          [JENKINS-24788] Cannot run program "/bin/java" on maven 3 projects

          Stephane Odul added a comment - - edited

          I specify the Java install to use per job with the JDK setting in the config page (see job-config-jdk.png attachment), and each JDK is either downloaded from our artifactory repo, from Sun/Oracle, or simply pointed to the one managed with the OS by Salt (like Puppet or Chef), see jdk-installations.png.

          Stephane Odul added a comment - - edited I specify the Java install to use per job with the JDK setting in the config page (see job-config-jdk.png attachment), and each JDK is either downloaded from our artifactory repo, from Sun/Oracle, or simply pointed to the one managed with the OS by Salt (like Puppet or Chef), see jdk-installations.png.

          Stephane Odul added a comment -

          Issue is still present with 1.584.

          Stephane Odul added a comment - Issue is still present with 1.584.

          James LeVeque added a comment -

          Did some further investigating on our end and found this issue was being caused by the labels on our JDK Installers.

          Jobs that were consistently failing were set to use an installer with the label "linux" (as seen in jdk-installations.jpg, attached). However, none of our slaves were actually labeled "linux" in Jenkins. When a build would start, Jenkins would check the prescribed JDK, look over its installers, see that none of them match its labels, and move on to the default JDK setting: /bin/java

          We've fixed the label misalignment on our Jenkins instance and all builds are accepting these JDKs without incident.

          This said:

          • While the problem was on our end, there were no errors or warnings to point us in the right direction. Something along the lines of "Label Mismatch: ${yourDesiredJDKSetting} has no valid JDK installers for ${thisSlave}. Using default JDK settings." would have been fantastic. Even something as simple as "No valid JDK installers found. Using default JDK settings." would have been a clue.
          • I found this label mismatch was killing Maven jobs and Freeform jobs using the "Invoke Maven 3" Build Task, but Freeform jobs using the "Invoke top-level Maven targets" step were running fine. I'm not sure what JDK they were using, though. Certainly not the JDK we set (which the mismatch should ignore) or the default /bin/java (which doesn't exist). This could be a nasty bug to people who use that build step and want to control the version of Java on a per-job basis.
          • I think the bin/java/ problem "after a slave is started", as mentioned in the description, is a separate-but-related issue. Fresh after a restart, a slave has some but not all of its labels set. It has hardcoded labels we use to state "Yes, this slave can do maven builds", but lacks environment-based labels that are used by our JDK installers. We generate those labels with the platformlabeler plugin, so I believe this plugin occasionally 'takes too long' to trigger and any builds that run in the meantime are doomed to fail. (Note: I haven't verified this bad-label state, but it seems likely now that we understand the JDK issue explored here.)

          James LeVeque added a comment - Did some further investigating on our end and found this issue was being caused by the labels on our JDK Installers. Jobs that were consistently failing were set to use an installer with the label "linux" (as seen in jdk-installations.jpg, attached). However, none of our slaves were actually labeled "linux" in Jenkins. When a build would start, Jenkins would check the prescribed JDK, look over its installers, see that none of them match its labels, and move on to the default JDK setting: /bin/java We've fixed the label misalignment on our Jenkins instance and all builds are accepting these JDKs without incident. This said: While the problem was on our end, there were no errors or warnings to point us in the right direction. Something along the lines of "Label Mismatch: ${yourDesiredJDKSetting} has no valid JDK installers for ${thisSlave}. Using default JDK settings." would have been fantastic. Even something as simple as "No valid JDK installers found. Using default JDK settings." would have been a clue. I found this label mismatch was killing Maven jobs and Freeform jobs using the "Invoke Maven 3" Build Task, but Freeform jobs using the "Invoke top-level Maven targets" step were running fine. I'm not sure what JDK they were using, though. Certainly not the JDK we set (which the mismatch should ignore) or the default /bin/java (which doesn't exist). This could be a nasty bug to people who use that build step and want to control the version of Java on a per-job basis. I think the bin/java/ problem "after a slave is started", as mentioned in the description, is a separate-but-related issue. Fresh after a restart, a slave has some but not all of its labels set. It has hardcoded labels we use to state "Yes, this slave can do maven builds", but lacks environment-based labels that are used by our JDK installers. We generate those labels with the platformlabeler plugin, so I believe this plugin occasionally 'takes too long' to trigger and any builds that run in the meantime are doomed to fail. (Note: I haven't verified this bad-label state, but it seems likely now that we understand the JDK issue explored here.)

          Mark Waite added a comment -

          My slave label management was simplified when I discovered the implied labels plugin, combined with the Hudson platformLabeler plugin. The platformLabeler plugin automatically assigns labels to slaves based on their operating system and hardware. The implied labels plugin allows me to declare that any computer with the label Ubuntu or Debian or Red Hat should be automatically labeled as linux.

          Mark Waite added a comment - My slave label management was simplified when I discovered the implied labels plugin, combined with the Hudson platformLabeler plugin. The platformLabeler plugin automatically assigns labels to slaves based on their operating system and hardware. The implied labels plugin allows me to declare that any computer with the label Ubuntu or Debian or Red Hat should be automatically labeled as linux.

          Daniel Beck added a comment -

          I found this label mismatch was killing Maven jobs and Freeform jobs using the "Invoke Maven 3" Build Task, but Freeform jobs using the "Invoke top-level Maven targets" step were running fine. I'm not sure what JDK they were using, though. Certainly not the JDK we set (which the mismatch should ignore) or the default /bin/java (which doesn't exist). This could be a nasty bug to people who use that build step and want to control the version of Java on a per-job basis.

          As it's a freestyle project, just run a batch or shell build step and print environment variables. Look for JAVA_HOME.

          While the problem was on our end, there were no errors or warnings to point us in the right direction. Something along the lines of "Label Mismatch: ${yourDesiredJDKSetting} has no valid JDK installers for ${thisSlave}. Using default JDK settings." would have been fantastic. Even something as simple as "No valid JDK installers found. Using default JDK settings." would have been a clue.

          File an improvement against the core component. Assign it to me.

          Daniel Beck added a comment - I found this label mismatch was killing Maven jobs and Freeform jobs using the "Invoke Maven 3" Build Task, but Freeform jobs using the "Invoke top-level Maven targets" step were running fine. I'm not sure what JDK they were using, though. Certainly not the JDK we set (which the mismatch should ignore) or the default /bin/java (which doesn't exist). This could be a nasty bug to people who use that build step and want to control the version of Java on a per-job basis. As it's a freestyle project, just run a batch or shell build step and print environment variables. Look for JAVA_HOME. While the problem was on our end, there were no errors or warnings to point us in the right direction. Something along the lines of "Label Mismatch: ${yourDesiredJDKSetting} has no valid JDK installers for ${thisSlave}. Using default JDK settings." would have been fantastic. Even something as simple as "No valid JDK installers found. Using default JDK settings." would have been a clue. File an improvement against the core component. Assign it to me.

          jminne added a comment -

          James is correct. This is a usability bug. Thank you James!

          jminne added a comment - James is correct. This is a usability bug. Thank you James!

          Daniel Beck added a comment -

          JENKINS-26940 is a duplicate of this issue, and I suggested the following there:

          Started by user anonymous
          Building in workspace /Users/danielbeck/Projects/Jenkins/jenkins_daniel-beck/war/work/jobs/JENKINS-26940/workspace
          Tool installer "Install from http://archive.apache.org/dist/ant/binaries/apache-ant-1.9.4-bin.tar.gz" cannot be run on the node "Jenkins"
          FATAL: Cannot find executable from the chosen Ant installation "foo"
          Build step 'Invoke Ant' marked build as failure
          Finished: FAILURE

          Would that work for you?

          Daniel Beck added a comment - JENKINS-26940 is a duplicate of this issue, and I suggested the following there: Started by user anonymous Building in workspace /Users/danielbeck/Projects/Jenkins/jenkins_daniel-beck/war/work/jobs/JENKINS-26940/workspace Tool installer "Install from http: //archive.apache.org/dist/ant/binaries/apache-ant-1.9.4-bin.tar.gz" cannot be run on the node "Jenkins" FATAL: Cannot find executable from the chosen Ant installation "foo" Build step 'Invoke Ant' marked build as failure Finished: FAILURE Would that work for you?

          杨 唐 added a comment -

          try : ln -s ${which java} /bin/java

          杨 唐 added a comment - try : ln -s ${which java} /bin/java

          Peter Rader added a comment -

          Thanks i had a simmilar message:

          Cannot run program "java"

          ln -s solved my problem too.

          Peter Rader added a comment - Thanks i had a simmilar message: Cannot run program "java" ln -s solved my problem too.

          Where exactly do you run `ln -s`? Same directory as the project, or where your java tools are being executed from?

          Igor Ganapolsky added a comment - Where exactly do you run `ln -s`? Same directory as the project, or where your java tools are being executed from?

            Unassigned Unassigned
            sodul Stephane Odul
            Votes:
            2 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated: