[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

    [ 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