Actually, that turns out to be insufficient. I just hit the case again with an already-built instance that takes significantly less than the idle timer to boot from stopped.

It looks like it's an issue if the build time takes longer than the timeout and there's a

Output for node launch looks like:

Starting existing instance: i-205dcf62 result:{StartingInstances: [{InstanceId: i-205dcf62,CurrentState: {Code: 0,Name: pending},PreviousState: {Code: 80,Name: stopped}}]}
Waiting for SSH to come up. Sleeping 5.
Connecting to 10.0.1.206 on port 22, with timeout 10000.
Waiting for SSH to come up. Sleeping 5.
Connecting to 10.0.1.206 on port 22, with timeout 10000.

(repeating endlessly), but when the node state is examined in AWS it's shown as stopped.

It's not clear from the ec2 plugin logs why this is happening; they look fairly reasonable:

Jul 16, 2014 7:58:55 AM INFO hudson.plugins.ec2.EC2RetentionStrategy _check
Idle timeout: Amazon Linux 2012.09 EBS 64-bit  (i-205dcf62)
Jul 16, 2014 7:58:55 AM INFO hudson.plugins.ec2.EC2AbstractSlave idleTimeout
EC2 instance idle time expired: i-205dcf62
Jul 16, 2014 7:58:55 AM INFO hudson.plugins.ec2.EC2AbstractSlave stop
EC2 instance stopped: i-205dcf62

those are logs for hudson.plugins.ec2 at log level FINEST.

I'm still speculating that there's a race - or two - here. It's not clear if this is the same one as above, or if this is another issue with a race between requesting a new instance and idle timeout.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira

--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to