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

1.487: Automatic JNLP installation breaks Xserve OS X slaves

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: slave-setup-plugin
    • Labels:
      None
    • Environment:
      Host: Arch Linux x86-64
      Slave: OS X 10.8 x86-64
    • Similar Issues:
      Show 5 results

      Description

      Since 1.487, Jenkins apparently attempts to run a graphical JNLP installer on all OS X slaves. This is a bad idea because some OS X slaves (such as Xserve-based ones) will not let the jenkins user connect to a window manager, so starting the slave connection always fails.

      A fix suggested by Kenny Ayers on the mailing list is to pass -Djava.awt.headless=true to the JVM, which works. But this should be a more readily accessible option in the slave settings UI - especially considering that this new behavior actively prevents previously working slaves from working.

      (I would even argue that this behavior should not be the default, but as long as there's an option, I'm happy.)

        Attachments

          Activity

          Hide
          aleksas aleksas added a comment -

          Same issue on mac 10.6.8 when running headless slave. Using jenkins v1.489.

          Adding -Djava.awt.headless=true to slave launch command line fixed the issue.

          Slave log prior to fix:
          Java.io.IOException: Unexpected termination of the channel
          at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50)
          Caused by: java.io.EOFException
          at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2553)
          at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1296)
          at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
          at hudson.remoting.Command.readFrom(Command.java:90)
          at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59)
          at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)
          Nov 7, 2012 11:19:16 PM hudson.remoting.jnlp.Main$CuiListener status
          INFO: Terminated

          Show
          aleksas aleksas added a comment - Same issue on mac 10.6.8 when running headless slave. Using jenkins v1.489. Adding -Djava.awt.headless=true to slave launch command line fixed the issue. Slave log prior to fix: Java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50) Caused by: java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2553) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1296) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) at hudson.remoting.Command.readFrom(Command.java:90) at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) Nov 7, 2012 11:19:16 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Terminated
          Hide
          brevilo Oliver Bock added a comment - - edited

          Same regression here on all my OS X build slaves (all types of hardware and OS X versions). The proposed workaround does the trick for the time being...

          Show
          brevilo Oliver Bock added a comment - - edited Same regression here on all my OS X build slaves (all types of hardware and OS X versions). The proposed workaround does the trick for the time being...

            People

            • Assignee:
              kohsuke Kohsuke Kawaguchi
              Reporter:
              alexrp Alex Rønne Petersen
            • Votes:
              6 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated: