Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Windows slaves fail to start via ssh"

(New page: <i>This problem is now better understood. See this post for more details. The work aroun...)
 
 
Line 1: Line 1:
<i>This problem is now better understood. See [[http://weblogs.java.net/blog/kohsuke/archive/2009/09/28/reading-stdin-may-cause-your-jvm-hang | this post]] for more details. The work around is implemented in 1.327.</i>
+
<i>This problem is now better understood. See [http://weblogs.java.net/blog/kohsuke/archive/2009/09/28/reading-stdin-may-cause-your-jvm-hang | this post] for more details. The work around is implemented in 1.327.</i>
  
 
Kohsuke observed a problem to connect to a Windows Hudson slave on several Hudson instances. They have the following symptoms:
 
Kohsuke observed a problem to connect to a Windows Hudson slave on several Hudson instances. They have the following symptoms:

Latest revision as of 15:30, 3 January 2013

This problem is now better understood. See | this post for more details. The work around is implemented in 1.327.

Kohsuke observed a problem to connect to a Windows Hudson slave on several Hudson instances. They have the following symptoms:

  1. Slave in question is a Windows machine (observed on XP, w2k and w2k3)
  2. The slave has an SSH daemon of some sort (so far it's only observed with MKS, although we don't know if it's related.)
  3. The master tries to connect to this Windows via SSH.
  4. The connection proceeds at least through halfway. You see some activities in the slave log, then it hangs.
  5. "jstack <PID>" hangs
  6. Process explorer fails to show the native thread dump in the "threads" tab of the process property dialog.

If your situation fits this description, please add a comment to describe your environment, and try the following work around.

  1. Specify the JVM options by clicking the "advanced" button in the configuration page of the slave. Set "-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=25589" as the JVM option. The port number 25589 can be anything.
  2. Restart Husdon, just to really make sure that Hudson master is attempting a connection in a clean state.

Back to the top