Slaves shown as duplicate after VM reboots
- CloudBees Jenkins Operations Center
When you recreated/killed the VMs the effect is similar to the one which will happen in case you directly remove the network connection of a shared slave. The shared slave will not notify Jenkins that the connection is off so Jenkins continue thinking that there is still a connection alive with this shared slave. Jenkins uses the ping thread in order to kill a connection when there is not an answer back from a slave after 4 minutes by default.
In case ping thread is disabled with ‘-Dhudson.remoting.Launcher.pingIntervalSec=-1’ the OS will kill the connection after a timeout which depends on the OS.
So in case you restart the VMs, the connections will be re-created, but the IDs of each shared slave will be different even if the name of the shared slave is the same. Notice that slaves are identified internally by IDs and not by the name we use when declaring them on Jenkins GUI.
To avoid this, we recommend:
- Quitting the JNLP slave on the client - just make sure the OS is up long enough to send the TCP SYN and get it acknowledged.
- Taking the shared cloud/shared slave to a “offline” status from the GUI would at least make sure that they where not picked up whilst terminating (or picked up when they are dead).