Jenkins Windows Slave loses connection immediately

[Markus Ewald]

I have the following setup:
- A Linux (amd64) server running Jenkins 1.398 in TomCat 7 with the
Sun JDK 1.6.0_24
- VirtualBox 3.2.12 providing a Windows 7 SP1 (x86) system, which is
running Jenkins' slave on Sun JDK 1.6.0_24

Networking from guest to host is configured as NAT -- the guest can
access the Jenkins web interface in its browser without any trouble.
My builds require GUI interaction in their tests, so I decided to run
the Jenkins slave via JNLP. This is my startup script:

@echo off
if exist slave.jar del slave.jar > nul
wget http://10.0.2.2:8080/jenkins/jnlpJars/slave.jar
java -jar slave.jar -jnlpUrl http://10.0.2.2:8080/jenkins/computer/win7x86/slave-agent.jnlp

However, the connection is lost the moment it is established. This is
what I see on the slave side:

INFO: Hudson agent is running in headless mode.
INFO: Locating server among [http://10.0.2.2:8080/jenkins/]
INFO: Connecting to 10.0.2.2:38416
INFO: Handshaking
INFO: Connected
SEVERE: I/O error in channel channel
java.io.IOException: Unexpected termination of the channel
at hudson.remoting.Channel$ReaderThread.run(Channel.java:953)
Caused by: java.io.EOFException
at java.io.ObjectInputStream
$BlockDataInputStream.peekByte(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at hudson.remoting.Channel$ReaderThread.run(Channel.java:947)
INFO: Terminated

The server says:

Connection was broken
java.net.SocketException: Socket closed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at java.io.ObjectInputStream
$PeekInputStream.peek(ObjectInputStream.java:2248)
at java.io.ObjectInputStream
$BlockDataInputStream.peek(ObjectInputStream.java:2541)
at java.io.ObjectInputStream
$BlockDataInputStream.peekByte(ObjectInputStream.java:2551)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1296)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at hudson.remoting.Channel$ReaderThread.run(Channel.java:947)

Some googling revealed one user having this error message server-sided
when using OpenJDK instead of Sun's JDK, but that doesn't sound like
it's got anything in common with my problem here.

The strange thing is that it seems to be handshaking and connecting
alright at first. I wonder if there would be anything useful in the
java.io.EOFException's message (dunno if Java would print this if the
exception is attached via .initCause(), probably not).

Any ideas? Tips for debugging?

[Markus Ewald]

In the meantime, I tried
- installed OpenVPN on the slave to work around any possible
VirtualBox network issues
- fiddled with the OpenVPN configuration so Windows 7 doesn't see it
as an "unidentified network"
- enabled security (manage jenkins -> configure system) so I could
specify a fixed JNLP port
- added Firewall rules to the slave to let traffic on the now fixed
port in and out

and eventually the master logs changed to

hudson.util.IOException2: Failed to copy /home/jenkins/plugins/
maven-plugin/WEB-INF/lib/maven-agent-1.398.jar to D:\maven-agent.jar

which sounds quite logical given that I entered D:\ as the remote FS
root and my slave doesn't have a D:\ partition yet. However... the
error message on the slave side still read

java.io.IOException: Unexpected termination of the channel

Now I'm not sure at which point the master-side error message changed
- it had to be after one of the above 4 changes - but after adding a D:
\ partition, the slave runs well. I was watching the slave-side error
message all the time, but apparently the model is that the slave
communicates its error back to the master, which logs it and cuts the
slave off. As a result, all the slave will complain about is that its
connection was unexpectedly severed.

It might be useful to make this a bit more obvious (maybe the slave
console could show that it's not the right place for troubleshooting
because errors will not be shown slave-side -- alternatively, perhaps
the slave could log errors to the console before forwarding them to
the master)