-
Bug
-
Resolution: Unresolved
-
Major
A user of the SSH plugin encountered a build which could not be interrupted from the UI:
at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:150) at java.net.SocketInputStream.read(SocketInputStream.java:121) at java.net.SocketInputStream.read(SocketInputStream.java:203) at com.jcraft.jsch.IO.getByte(IO.java:73) at com.jcraft.jsch.Session.connect(Session.java:230) at com.jcraft.jsch.Session.connect(Session.java:150) at org.jvnet.hudson.plugins.SSHSite.createSession(SSHSite.java:132) at org.jvnet.hudson.plugins.SSHSite.executeCommand(SSHSite.java:142) at org.jvnet.hudson.plugins.SSHBuilder.perform(SSHBuilder.java:57)
Normally TCP timeouts would kill such a connection after a couple of minutes, but this depends on network/router configuration. Unfortunately blocking socket methods do not respond to Thread.interrupt (at least on Sun-based JREs) so there is no way Jenkins can convince SSHBuilder to stop what it was doing. Thread.stop does work in such cases but it is an extreme measure that Jenkins core currently does not take.
Workaround, besides using a plain shell step running ssh: my https://github.com/jglick/jkillthread
Build steps making uninterruptible blocking calls could in principle be enhanced to monitor the interrupted status of the executor thread and stop it if it has been interrupted for a minute or so without apparent effect. Or Jenkins core could be made to get impatient after two or three interrupt requests have been sent to a build and it is still running (especially if no new log messages have appeared), and stop the thread itself.