[JIRA] Commented: (HUDSON-7219) EC2 slaves fail to launch after upgrade from 1.8 -> 1.9

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[JIRA] Commented: (HUDSON-7219) EC2 slaves fail to launch after upgrade from 1.8 -> 1.9

Kohsuke Kawaguchi
Administrator

    [ http://issues.hudson-ci.org/browse/HUDSON-7219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144547#action_144547 ]

mrdavidlaing commented on HUDSON-7219:
--------------------------------------

I had a similar issue trying to start a Windows slave (using the ec2-sshd project).

For me, I was missing a c:\tmp folder, so the /tmp/slave.jar wasn't being created properly.

The IOException is a bit of a red herring in my case.

For what its worth, I found the ec2-sshd method very slow compared to launching the agent via JNLP.

> EC2 slaves fail to launch after upgrade from 1.8 -> 1.9
> -------------------------------------------------------
>
>                 Key: HUDSON-7219
>                 URL: http://issues.hudson-ci.org/browse/HUDSON-7219
>             Project: Hudson
>          Issue Type: Bug
>          Components: ec2
>            Reporter: mjmac
>            Assignee: kohsuke
>
> After upgrading the plugin from 1.8 -> 1.9, I could no longer launch EC2 slaves.  A log excerpt would show something like the following:
> ...
> Verifying that java exists
> java full version "1.6.0_15-b03"
> Copying slave.jar
> Launching slave agent
> ...
> Then an IOException about the channel being closed unexpectedly (sorry, didn't capture the trace).  Eventually the launch would time out and it would try again and again with no success.
> After looking at the svn log I noticed the following change (r33881), which seemed to be where it was dying:
> -            sess.execCommand("java -jar /tmp/slave.jar");
> +            sess.execCommand("java " + computer.getNode().jvmopts + " -jar /tmp/slave.jar");
> It occurred to me that maybe the jvmopts value didn't exist in the 1.8-style EC2 config, so I saved the AMI with "-verbose" in the JVM options field, saved the config, and launched an EC2 slave successfully.  I killed that slave, blanked out the JVM options field, saved again, and again successfully launched an EC2 slave.
> Maybe the plugin needs to guard against a null value from older configs or else massage old configs to fit into the new "schema" or something?

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.hudson-ci.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira