Quantcast

slave.jar does not work

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

slave.jar does not work

Eric Lefevre-Ardant
All,

A colleague and I have been trying to deploy Hudson slaves for version 1.233. It works rather well when launching the client agent though JNLP (though it is serious work to synchronize the various configurations).
However, it fails utterly with slave.jar. Here is all we get:

F:\>java -jar slave.jar
    ¼Ý ?

and then it does not return to the command line.
This could be OK, but of course the master reports the slave as being disconnected.

We thought that is was related to the local configuration, but we got the same error (with slight variations in the 3 characters being displayed) under HP-UX, Windows 2000 (cmd.exe and cygwin), and Windows XP, each on a separate machine. All are using some version of JDK 1.5, except one that is using 1.6.

We also thought that the jar file was corrupted, but it can be unzipped with no problem, and I also tried with an older version (1.210 I think) and it didn't make any difference.

This implies that noone has been using slave.jar in a long time. I cannot believe this is true.

Can anybody help?

Many thanks,

Eric

PS: it probably does mean much, but when stopping the JVM with Ctrl-C, we get
F:\>java -jar slave.jar
    ¼Ý ?Exception in thread "main" java.io.EOFException: unexpected stream termination
        at hudson.remoting.Channel.<init>(Channel.java:260)
        at hudson.remoting.Channel.<init>(Channel.java:208)
        at hudson.remoting.Launcher.main(Launcher.java:57)
        at hudson.remoting.Launcher.main(Launcher.java:43)

which probably makes sense, since the slave is supposed to be listening to some port
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: slave.jar does not work

Tomas Musil
Hi,
seems like you are launching slave.jar *locally*, but you have to launch
it *remotely* to make the connection! These weird characters do not mean
JAR is broken...
All you have to do is to launch slave.jar from master machine, i.e. in
Hudson configuration set up launch command to something like:
ssh [hidden email] java -jar slave.jar

assuming that:
1) your slave "myslave.mydomain" has user "hudson",
2) and you are able to log from machine where is running master to slave
machine without password (using RSA keys)
3) "java" is on $PATH on slave machine

Tomas

Eric Lefevre wrote:

> All,
>
> A colleague and I have been trying to deploy Hudson slaves for version
> 1.233. It works rather well when launching the client agent though
> JNLP (though it is serious work to synchronize the various
> configurations).
> However, it fails utterly with slave.jar. Here is all we get:
>
> F:\>java -jar slave.jar
>     ¼Ý ?
>
> and then it does not return to the command line.
> This could be OK, but of course the master reports the slave as being
> disconnected.
>
> We thought that is was related to the local configuration, but we got
> the same error (with slight variations in the 3 characters being
> displayed) under HP-UX, Windows 2000 (cmd.exe and cygwin), and Windows
> XP, each on a separate machine. All are using some version of JDK 1.5,
> except one that is using 1.6.
>
> We also thought that the jar file was corrupted, but it can be
> unzipped with no problem, and I also tried with an older version
> (1.210 I think) and it didn't make any difference.
>
> This implies that noone has been using slave.jar in a long time. I
> cannot believe this is true.
>
> Can anybody help?
>
> Many thanks,
>
> Eric
>
> PS: it probably does mean much, but when stopping the JVM with Ctrl-C,
> we get
> F:\>java -jar slave.jar
>     ¼Ý ?Exception in thread "main" java.io.EOFException: unexpected
> stream termination
>         at hudson.remoting.Channel.<init>(Channel.java:260)
>         at hudson.remoting.Channel.<init>(Channel.java:208)
>         at hudson.remoting.Launcher.main(Launcher.java:57)
>         at hudson.remoting.Launcher.main(Launcher.java:43)
>
> which probably makes sense, since the slave is supposed to be
> listening to some port


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: slave.jar does not work

Eric Lefevre-Ardant
Hi Tomas, thanks for responding

But I don't follow you... I don't see how "ssh [hidden email] java -jar slave.jar" would make a difference from logging in manually and typing "java -jar slave.jar", apart from the obvious PATH issues.
Besides, how is the whole ssh command any different from opening ssh manually (with Putty) and typing "java -jar slave.jar", which is what we did when using HP-UX?

Also, typing "java -jar slave.jar" is actually clearly recommended here: https://hudson.dev.java.net/masterSlave.html

Anyway, just to be safe, we tried your recommendation. The display we get is exactly the same.

Eric

2008/7/9 Tomas Musil <[hidden email]>:
Hi,
seems like you are launching slave.jar *locally*, but you have to launch it *remotely* to make the connection! These weird characters do not mean JAR is broken...
All you have to do is to launch slave.jar from master machine, i.e. in Hudson configuration set up launch command to something like:
ssh [hidden email] java -jar slave.jar

assuming that:
1) your slave "myslave.mydomain" has user "hudson",
2) and you are able to log from machine where is running master to slave machine without password (using RSA keys)
3) "java" is on $PATH on slave machine

Tomas


Eric Lefevre wrote:
All,

A colleague and I have been trying to deploy Hudson slaves for version 1.233. It works rather well when launching the client agent though JNLP (though it is serious work to synchronize the various configurations).
However, it fails utterly with slave.jar. Here is all we get:

F:\>java -jar slave.jar
   ¼Ý ?

and then it does not return to the command line.
This could be OK, but of course the master reports the slave as being disconnected.

We thought that is was related to the local configuration, but we got the same error (with slight variations in the 3 characters being displayed) under HP-UX, Windows 2000 (cmd.exe and cygwin), and Windows XP, each on a separate machine. All are using some version of JDK 1.5, except one that is using 1.6.

We also thought that the jar file was corrupted, but it can be unzipped with no problem, and I also tried with an older version (1.210 I think) and it didn't make any difference.

This implies that noone has been using slave.jar in a long time. I cannot believe this is true.

Can anybody help?

Many thanks,

Eric

PS: it probably does mean much, but when stopping the JVM with Ctrl-C, we get
F:\>java -jar slave.jar
   ¼Ý ?Exception in thread "main" java.io.EOFException: unexpected stream termination
       at hudson.remoting.Channel.<init>(Channel.java:260)
       at hudson.remoting.Channel.<init>(Channel.java:208)
       at hudson.remoting.Launcher.main(Launcher.java:57)
       at hudson.remoting.Launcher.main(Launcher.java:43)

which probably makes sense, since the slave is supposed to be listening to some port


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: slave.jar does not work

Tomas Musil
The key thing is that this command has to be run Hudson itself. You do
not need to type anywhere anything. Therefore:
1) go to hudson on master
2) click "manage hudson"
3) click "configure executors" (this is new in recent Hudson in
previous  versions these setting were available in "Configure system")
4) fill in some information about your slave (# of executors, name, ...)
5) in "Launch method" choose "Launch slave by command from master"
6) fill in launch command " ssh [hidden email] java -jar slave.jar"
7) save configuration
8) at Hudson's dashboard, you should see now your new slave, if
everything is fine, slave is online, otherwise slave is offline - in
such a case you can look at log of slave and debug what went wrong.

Sorry my steps are not too detailed, I'm pretty sure someone points you
to some detailed HOWTO e.g. on wiki...

HTH

Tomas

Eric Lefevre wrote:

> Hi Tomas, thanks for responding
>
> But I don't follow you... I don't see how "ssh [hidden email]
> java -jar slave.jar" would make a difference from logging in manually
> and typing "java -jar slave.jar", apart from the obvious PATH issues.
> Besides, how is the whole ssh command any different from opening ssh
> manually (with Putty) and typing "java -jar slave.jar", which is what
> we did when using HP-UX?
>
> Also, typing "java -jar slave.jar" is actually clearly recommended
> here: https://hudson.dev.java.net/masterSlave.html
>
> Anyway, just to be safe, we tried your recommendation. The display we
> get is exactly the same.
>
> Eric
>
> 2008/7/9 Tomas Musil <[hidden email] <mailto:[hidden email]>>:
>
>     Hi,
>     seems like you are launching slave.jar *locally*, but you have to
>     launch it *remotely* to make the connection! These weird
>     characters do not mean JAR is broken...
>     All you have to do is to launch slave.jar from master machine,
>     i.e. in Hudson configuration set up launch command to something like:
>     ssh [hidden email] java -jar slave.jar
>
>     assuming that:
>     1) your slave "myslave.mydomain" has user "hudson",
>     2) and you are able to log from machine where is running master to
>     slave machine without password (using RSA keys)
>     3) "java" is on $PATH on slave machine
>
>     Tomas
>
>
>     Eric Lefevre wrote:
>
>         All,
>
>         A colleague and I have been trying to deploy Hudson slaves for
>         version 1.233. It works rather well when launching the client
>         agent though JNLP (though it is serious work to synchronize
>         the various configurations).
>         However, it fails utterly with slave.jar. Here is all we get:
>
>         F:\>java -jar slave.jar
>            ¼Ý ?
>
>         and then it does not return to the command line.
>         This could be OK, but of course the master reports the slave
>         as being disconnected.
>
>         We thought that is was related to the local configuration, but
>         we got the same error (with slight variations in the 3
>         characters being displayed) under HP-UX, Windows 2000 (cmd.exe
>         and cygwin), and Windows XP, each on a separate machine. All
>         are using some version of JDK 1.5, except one that is using 1.6.
>
>         We also thought that the jar file was corrupted, but it can be
>         unzipped with no problem, and I also tried with an older
>         version (1.210 I think) and it didn't make any difference.
>
>         This implies that noone has been using slave.jar in a long
>         time. I cannot believe this is true.
>
>         Can anybody help?
>
>         Many thanks,
>
>         Eric
>
>         PS: it probably does mean much, but when stopping the JVM with
>         Ctrl-C, we get
>         F:\>java -jar slave.jar
>            ¼Ý ?Exception in thread "main" java.io.EOFException:
>         unexpected stream termination
>                at hudson.remoting.Channel.<init>(Channel.java:260)
>                at hudson.remoting.Channel.<init>(Channel.java:208)
>                at hudson.remoting.Launcher.main(Launcher.java:57)
>                at hudson.remoting.Launcher.main(Launcher.java:43)
>
>         which probably makes sense, since the slave is supposed to be
>         listening to some port
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: slave.jar does not work

stephenconnolly
In reply to this post by Eric Lefevre-Ardant
the slave jar uses stdout and stdin to communicate with the master. therefore _hudson_ needs to start slave.jar on the slave from the master so that is has stdout and stdin connected to Hudson


Sent from my iPod

On 9 Jul 2008, at 17:13, "Eric Lefevre" <[hidden email]> wrote:

Hi Tomas, thanks for responding

But I don't follow you... I don't see how "ssh [hidden email] java -jar slave.jar" would make a difference from logging in manually and typing "java -jar slave.jar", apart from the obvious PATH issues.
Besides, how is the whole ssh command any different from opening ssh manually (with Putty) and typing "java -jar slave.jar", which is what we did when using HP-UX?

Also, typing "java -jar slave.jar" is actually clearly recommended here: https://hudson.dev.java.net/masterSlave.html

Anyway, just to be safe, we tried your recommendation. The display we get is exactly the same.

Eric

2008/7/9 Tomas Musil <[hidden email]>:
Hi,
seems like you are launching slave.jar *locally*, but you have to launch it *remotely* to make the connection! These weird characters do not mean JAR is broken...
All you have to do is to launch slave.jar from master machine, i.e. in Hudson configuration set up launch command to something like:
ssh [hidden email] java -jar slave.jar

assuming that:
1) your slave "myslave.mydomain" has user "hudson",
2) and you are able to log from machine where is running master to slave machine without password (using RSA keys)
3) "java" is on $PATH on slave machine

Tomas


Eric Lefevre wrote:
All,

A colleague and I have been trying to deploy Hudson slaves for version 1.233. It works rather well when launching the client agent though JNLP (though it is serious work to synchronize the various configurations).
However, it fails utterly with slave.jar. Here is all we get:

F:\>java -jar slave.jar
   ¼Ý ?

and then it does not return to the command line.
This could be OK, but of course the master reports the slave as being disconnected.

We thought that is was related to the local configuration, but we got the same error (with slight variations in the 3 characters being displayed) under HP-UX, Windows 2000 (cmd.exe and cygwin), and Windows XP, each on a separate machine. All are using some version of JDK 1.5, except one that is using 1.6.

We also thought that the jar file was corrupted, but it can be unzipped with no problem, and I also tried with an older version (1.210 I think) and it didn't make any difference.

This implies that noone has been using slave.jar in a long time. I cannot believe this is true.

Can anybody help?

Many thanks,

Eric

PS: it probably does mean much, but when stopping the JVM with Ctrl-C, we get
F:\>java -jar slave.jar
   ¼Ý ?Exception in thread "main" java.io.EOFException: unexpected stream termination
       at hudson.remoting.Channel.<init>(Channel.java:260)
       at hudson.remoting.Channel.<init>(Channel.java:208)
       at hudson.remoting.Launcher.main(Launcher.java:57)
       at hudson.remoting.Launcher.main(Launcher.java:43)

which probably makes sense, since the slave is supposed to be listening to some port


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: slave.jar does not work

Kohsuke Kawaguchi
Administrator
In reply to this post by Eric Lefevre-Ardant

Tomas and Stephen are correct about what you are doing wrong, but I
think slave.jar can detect whether it's launched from interactive
console, and print out a warning message in such a case. I should
probably do that, as I don't think you are the first to make this mistake.

Another thing that I wonder is whether we should improve slave.jar so
that it can be started independently (for example as a Windows service)
and then connect to the master through TCP connection.

You'd then be able to launch it like "java -jar slave.jar
http://server.localdomain/hudson/"

Would that something you'd like to see?

Eric Lefevre wrote:

> All,
>
> A colleague and I have been trying to deploy Hudson slaves for version 1.233. It
> works rather well when launching the client agent though JNLP (though it is
> serious work to synchronize the various configurations).
> However, it fails utterly with slave.jar. Here is all we get:
>
> F:\>java -jar slave.jar
>     ¼Ý ?
>
> and then it does not return to the command line.
> This could be OK, but of course the master reports the slave as being disconnected.
>
> We thought that is was related to the local configuration, but we got the same
> error (with slight variations in the 3 characters being displayed) under HP-UX,
> Windows 2000 (cmd.exe and cygwin), and Windows XP, each on a separate machine.
> All are using some version of JDK 1.5, except one that is using 1.6.
>
> We also thought that the jar file was corrupted, but it can be unzipped with no
> problem, and I also tried with an older version (1.210 I think) and it didn't
> make any difference.
>
> This implies that noone has been using slave.jar in a long time. I cannot
> believe this is true.
>
> Can anybody help?
>
> Many thanks,
>
> Eric
>
> PS: it probably does mean much, but when stopping the JVM with Ctrl-C, we get
> F:\>java -jar slave.jar
>     ¼Ý ?Exception in thread "main" java.io.EOFException: unexpected stream
> termination
>         at hudson.remoting.Channel.<init>(Channel.java:260)
>         at hudson.remoting.Channel.<init>(Channel.java:208)
>         at hudson.remoting.Launcher.main(Launcher.java:57)
>         at hudson.remoting.Launcher.main(Launcher.java:43)
>
> which probably makes sense, since the slave is supposed to be listening to some port

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: slave.jar does not work

stephenconnolly
I wonder if he's trying to avoid adding a configuration for each slave  
because the jnlp slave already provides this functionality (in essence)

I do think this is an important area of the slave launching that we  
need to look at. it should be a lot easier with the new hooks. in any  
case I'll need something like this for some of the vmware slaves

Sent from my iPod

On 9 Jul 2008, at 20:37, Kohsuke Kawaguchi <[hidden email]>  
wrote:

>
> Tomas and Stephen are correct about what you are doing wrong, but I  
> think slave.jar can detect whether it's launched from interactive  
> console, and print out a warning message in such a case. I should  
> probably do that, as I don't think you are the first to make this  
> mistake.
>
> Another thing that I wonder is whether we should improve slave.jar  
> so that it can be started independently (for example as a Windows  
> service) and then connect to the master through TCP connection.
>
> You'd then be able to launch it like "java -jar slave.jar http://server.localdomain/hudson/ 
> "
>
> Would that something you'd like to see?
>
> Eric Lefevre wrote:
>> All,
>> A colleague and I have been trying to deploy Hudson slaves for  
>> version 1.233. It works rather well when launching the client agent  
>> though JNLP (though it is serious work to synchronize the various  
>> configurations).
>> However, it fails utterly with slave.jar. Here is all we get:
>> F:\>java -jar slave.jar
>>    ¼Ý ?
>> and then it does not return to the command line.
>> This could be OK, but of course the master reports the slave as  
>> being disconnected.
>> We thought that is was related to the local configuration, but we  
>> got the same error (with slight variations in the 3 characters  
>> being displayed) under HP-UX, Windows 2000 (cmd.exe and cygwin),  
>> and Windows XP, each on a separate machine. All are using some  
>> version of JDK 1.5, except one that is using 1.6.
>> We also thought that the jar file was corrupted, but it can be  
>> unzipped with no problem, and I also tried with an older version  
>> (1.210 I think) and it didn't make any difference.
>> This implies that noone has been using slave.jar in a long time. I  
>> cannot believe this is true.
>> Can anybody help?
>> Many thanks,
>> Eric
>> PS: it probably does mean much, but when stopping the JVM with Ctrl-
>> C, we get
>> F:\>java -jar slave.jar
>>    ¼Ý ?Exception in thread "main" java.io.EOFException: unexpected
>>  stream termination
>>        at hudson.remoting.Channel.<init>(Channel.java:260)
>>        at hudson.remoting.Channel.<init>(Channel.java:208)
>>        at hudson.remoting.Launcher.main(Launcher.java:57)
>>        at hudson.remoting.Launcher.main(Launcher.java:43)
>> which probably makes sense, since the slave is supposed to be  
>> listening to some port
>
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: slave.jar does not work

Eric Lefevre-Ardant
That was not our goal (having a specific configuration per slave), though I do see how it would be useful. Indeed, we have often fumed when we realized that we had to have the same configuration on all slaves.

Thanks Tomas, Kohsuke and Stephen, I do understand now that we had to start slave.jar from the Hudson admin interface.

Kohsuke, I feel that this is not made clear in the masterSlave.html file. Are you OK with me updating this file? I reckon you check all such changes anyway, right?

Eric

2008/7/9 Stephen Connolly <[hidden email]>:
I wonder if he's trying to avoid adding a configuration for each slave because the jnlp slave already provides this functionality (in essence)

I do think this is an important area of the slave launching that we need to look at. it should be a lot easier with the new hooks. in any case I'll need something like this for some of the vmware slaves

Sent from my iPod


On 9 Jul 2008, at 20:37, Kohsuke Kawaguchi <[hidden email]> wrote:


Tomas and Stephen are correct about what you are doing wrong, but I think slave.jar can detect whether it's launched from interactive console, and print out a warning message in such a case. I should probably do that, as I don't think you are the first to make this mistake.

Another thing that I wonder is whether we should improve slave.jar so that it can be started independently (for example as a Windows service) and then connect to the master through TCP connection.

You'd then be able to launch it like "java -jar slave.jar http://server.localdomain/hudson/"

Would that something you'd like to see?

Eric Lefevre wrote:
All,
A colleague and I have been trying to deploy Hudson slaves for version 1.233. It works rather well when launching the client agent though JNLP (though it is serious work to synchronize the various configurations).
However, it fails utterly with slave.jar. Here is all we get:
F:\>java -jar slave.jar
  ¼Ý ?
and then it does not return to the command line.
This could be OK, but of course the master reports the slave as being disconnected.
We thought that is was related to the local configuration, but we got the same error (with slight variations in the 3 characters being displayed) under HP-UX, Windows 2000 (cmd.exe and cygwin), and Windows XP, each on a separate machine. All are using some version of JDK 1.5, except one that is using 1.6.
We also thought that the jar file was corrupted, but it can be unzipped with no problem, and I also tried with an older version (1.210 I think) and it didn't make any difference.
This implies that noone has been using slave.jar in a long time. I cannot believe this is true.
Can anybody help?
Many thanks,
Eric
PS: it probably does mean much, but when stopping the JVM with Ctrl-C, we get
F:\>java -jar slave.jar
  ¼Ý ?Exception in thread "main" java.io.EOFException: unexpected stream termination
      at hudson.remoting.Channel.<init>(Channel.java:260)
      at hudson.remoting.Channel.<init>(Channel.java:208)
      at hudson.remoting.Launcher.main(Launcher.java:57)
      at hudson.remoting.Launcher.main(Launcher.java:43)
which probably makes sense, since the slave is supposed to be listening to some port


--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: slave.jar does not work

Kohsuke Kawaguchi
Administrator
In reply to this post by stephenconnolly
Stephen Connolly wrote:
> I wonder if he's trying to avoid adding a configuration for each slave  
> because the jnlp slave already provides this functionality (in essence)

Right, but making JNLP work in a service management framework is
actually hard. You need some special tweak to make it headless, plus
logs don't go to stdout/stderr.

I think it's much simpler if you just needed to daemonize a console
application.


> I do think this is an important area of the slave launching that we  
> need to look at. it should be a lot easier with the new hooks. in any  
> case I'll need something like this for some of the vmware slaves
>
> Sent from my iPod
>
> On 9 Jul 2008, at 20:37, Kohsuke Kawaguchi <[hidden email]>  
> wrote:
>
>>
>> Tomas and Stephen are correct about what you are doing wrong, but I  
>> think slave.jar can detect whether it's launched from interactive  
>> console, and print out a warning message in such a case. I should  
>> probably do that, as I don't think you are the first to make this  
>> mistake.
>>
>> Another thing that I wonder is whether we should improve slave.jar  
>> so that it can be started independently (for example as a Windows  
>> service) and then connect to the master through TCP connection.
>>
>> You'd then be able to launch it like "java -jar slave.jar http://server.localdomain/hudson/ 
>> "
>>
>> Would that something you'd like to see?
>>
>> Eric Lefevre wrote:
>>> All,
>>> A colleague and I have been trying to deploy Hudson slaves for  
>>> version 1.233. It works rather well when launching the client agent  
>>> though JNLP (though it is serious work to synchronize the various  
>>> configurations).
>>> However, it fails utterly with slave.jar. Here is all we get:
>>> F:\>java -jar slave.jar
>>>    ???? ?
>>> and then it does not return to the command line.
>>> This could be OK, but of course the master reports the slave as  
>>> being disconnected.
>>> We thought that is was related to the local configuration, but we  
>>> got the same error (with slight variations in the 3 characters  
>>> being displayed) under HP-UX, Windows 2000 (cmd.exe and cygwin),  
>>> and Windows XP, each on a separate machine. All are using some  
>>> version of JDK 1.5, except one that is using 1.6.
>>> We also thought that the jar file was corrupted, but it can be  
>>> unzipped with no problem, and I also tried with an older version  
>>> (1.210 I think) and it didn't make any difference.
>>> This implies that noone has been using slave.jar in a long time. I  
>>> cannot believe this is true.
>>> Can anybody help?
>>> Many thanks,
>>> Eric
>>> PS: it probably does mean much, but when stopping the JVM with Ctrl-
>>> C, we get
>>> F:\>java -jar slave.jar
>>>    ???? ?Exception in thread "main" java.io.EOFException: unexpected
>>>  stream termination
>>>        at hudson.remoting.Channel.<init>(Channel.java:260)
>>>        at hudson.remoting.Channel.<init>(Channel.java:208)
>>>        at hudson.remoting.Launcher.main(Launcher.java:57)
>>>        at hudson.remoting.Launcher.main(Launcher.java:43)
>>> which probably makes sense, since the slave is supposed to be  
>>> listening to some port
>>
>>
>> --
>> Kohsuke Kawaguchi
>> Sun Microsystems                   [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: slave.jar does not work

Kohsuke Kawaguchi
Administrator
In reply to this post by Eric Lefevre-Ardant
Eric Lefevre wrote:

> That was not our goal (having a specific configuration per slave), though I do
> see how it would be useful. Indeed, we have often fumed when we realized that we
> had to have the same configuration on all slaves.
>
> Thanks Tomas, Kohsuke and Stephen, I do understand now that we had to start
> slave.jar from the Hudson admin interface.
>
> Kohsuke, I feel that this is not made clear in the masterSlave.html file. Are
> you OK with me updating this file? I reckon you check all such changes anyway,
> right?
HTML files under www should be all in Wiki now. Sounds like we need to
set a direct from masterSlave.html to the corresponding page in Wiki.

Can you do that for us, by any chance :-) ?

>
> Eric
>
> 2008/7/9 Stephen Connolly <[hidden email]
> <mailto:[hidden email]>>:
>
>     I wonder if he's trying to avoid adding a configuration for each slave
>     because the jnlp slave already provides this functionality (in essence)
>
>     I do think this is an important area of the slave launching that we need to
>     look at. it should be a lot easier with the new hooks. in any case I'll need
>     something like this for some of the vmware slaves
>
>     Sent from my iPod
>
>
>     On 9 Jul 2008, at 20:37, Kohsuke Kawaguchi <[hidden email]> wrote:
>
>
>         Tomas and Stephen are correct about what you are doing wrong, but I
>         think slave.jar can detect whether it's launched from interactive
>         console, and print out a warning message in such a case. I should
>         probably do that, as I don't think you are the first to make this mistake.
>
>         Another thing that I wonder is whether we should improve slave.jar so
>         that it can be started independently (for example as a Windows service)
>         and then connect to the master through TCP connection.
>
>         You'd then be able to launch it like "java -jar slave.jar
>         http://server.localdomain/hudson/"
>
>         Would that something you'd like to see?
>
>         Eric Lefevre wrote:
>
>             All,
>             A colleague and I have been trying to deploy Hudson slaves for
>             version 1.233. It works rather well when launching the client agent
>             though JNLP (though it is serious work to synchronize the various
>             configurations).
>             However, it fails utterly with slave.jar. Here is all we get:
>             F:\>java -jar slave.jar
>               ¼Ý ?
>             and then it does not return to the command line.
>             This could be OK, but of course the master reports the slave as
>             being disconnected.
>             We thought that is was related to the local configuration, but we
>             got the same error (with slight variations in the 3 characters being
>             displayed) under HP-UX, Windows 2000 (cmd.exe and cygwin), and
>             Windows XP, each on a separate machine. All are using some version
>             of JDK 1.5, except one that is using 1.6.
>             We also thought that the jar file was corrupted, but it can be
>             unzipped with no problem, and I also tried with an older version
>             (1.210 I think) and it didn't make any difference.
>             This implies that noone has been using slave.jar in a long time. I
>             cannot believe this is true.
>             Can anybody help?
>             Many thanks,
>             Eric
>             PS: it probably does mean much, but when stopping the JVM with
>             Ctrl-C, we get
>             F:\>java -jar slave.jar
>               ¼Ý ?Exception in thread "main" java.io.EOFException:
>             unexpected stream termination
>                   at hudson.remoting.Channel.<init>(Channel.java:260)
>                   at hudson.remoting.Channel.<init>(Channel.java:208)
>                   at hudson.remoting.Launcher.main(Launcher.java:57)
>                   at hudson.remoting.Launcher.main(Launcher.java:43)
>             which probably makes sense, since the slave is supposed to be
>             listening to some port
>
>
>
>         --
>         Kohsuke Kawaguchi
>         Sun Microsystems                   [hidden email]
>         <mailto:[hidden email]>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: slave.jar does not work

Aleksandar Kostadinov
In reply to this post by Kohsuke Kawaguchi
Kohsuke Kawaguchi wrote, On 12/23/-28158 09:59 PM (EEST):

> Stephen Connolly wrote:
>> I wonder if he's trying to avoid adding a configuration for each
>> slave  because the jnlp slave already provides this functionality (in
>> essence)
>
> Right, but making JNLP work in a service management framework is
> actually hard. You need some special tweak to make it headless, plus
> logs don't go to stdout/stderr.
>
> I think it's much simpler if you just needed to daemonize a console
> application.

Right! I currently am unable to launch a windows slave through telnet or
winexe because of line buffering. Not to talk black magic needed to go
to that point. I hope such an implementation would consider security
though as one wouldn't want to have a malicious slave attached to the
master.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: slave.jar does not work

Eric Lefevre-Ardant
In reply to this post by Kohsuke Kawaguchi
done. Also updated wiki to make it a little clearer to me.

Eric

2008/7/11 Kohsuke Kawaguchi <[hidden email]>:
Eric Lefevre wrote:
That was not our goal (having a specific configuration per slave), though I do see how it would be useful. Indeed, we have often fumed when we realized that we had to have the same configuration on all slaves.

Thanks Tomas, Kohsuke and Stephen, I do understand now that we had to start slave.jar from the Hudson admin interface.

Kohsuke, I feel that this is not made clear in the masterSlave.html file. Are you OK with me updating this file? I reckon you check all such changes anyway, right?

HTML files under www should be all in Wiki now. Sounds like we need to set a direct from masterSlave.html to the corresponding page in Wiki.

Can you do that for us, by any chance :-) ?


Eric

2008/7/9 Stephen Connolly <[hidden email] <mailto:[hidden email]>>:


   I wonder if he's trying to avoid adding a configuration for each slave
   because the jnlp slave already provides this functionality (in essence)

   I do think this is an important area of the slave launching that we need to
   look at. it should be a lot easier with the new hooks. in any case I'll need
   something like this for some of the vmware slaves

   Sent from my iPod


   On 9 Jul 2008, at 20:37, Kohsuke Kawaguchi <[hidden email]> wrote:


       Tomas and Stephen are correct about what you are doing wrong, but I
       think slave.jar can detect whether it's launched from interactive
       console, and print out a warning message in such a case. I should
       probably do that, as I don't think you are the first to make this mistake.

       Another thing that I wonder is whether we should improve slave.jar so
       that it can be started independently (for example as a Windows service)
       and then connect to the master through TCP connection.

       You'd then be able to launch it like "java -jar slave.jar
       http://server.localdomain/hudson/"

       Would that something you'd like to see?

       Eric Lefevre wrote:

           All,
           A colleague and I have been trying to deploy Hudson slaves for
           version 1.233. It works rather well when launching the client agent
           though JNLP (though it is serious work to synchronize the various
           configurations).
           However, it fails utterly with slave.jar. Here is all we get:
           F:\>java -jar slave.jar
             ¼Ý ?
           and then it does not return to the command line.
           This could be OK, but of course the master reports the slave as
           being disconnected.
           We thought that is was related to the local configuration, but we
           got the same error (with slight variations in the 3 characters being
           displayed) under HP-UX, Windows 2000 (cmd.exe and cygwin), and
           Windows XP, each on a separate machine. All are using some version
           of JDK 1.5, except one that is using 1.6.
           We also thought that the jar file was corrupted, but it can be
           unzipped with no problem, and I also tried with an older version
           (1.210 I think) and it didn't make any difference.
           This implies that noone has been using slave.jar in a long time. I
           cannot believe this is true.
           Can anybody help?
           Many thanks,
           Eric
           PS: it probably does mean much, but when stopping the JVM with
           Ctrl-C, we get
           F:\>java -jar slave.jar
             ¼Ý ?Exception in thread "main" java.io.EOFException:
           unexpected stream termination
                 at hudson.remoting.Channel.<init>(Channel.java:260)
                 at hudson.remoting.Channel.<init>(Channel.java:208)
                 at hudson.remoting.Launcher.main(Launcher.java:57)
                 at hudson.remoting.Launcher.main(Launcher.java:43)
           which probably makes sense, since the slave is supposed to be
           listening to some port



       --        Kohsuke Kawaguchi
       Sun Microsystems                   [hidden email]
       <mailto:[hidden email]>



   ---------------------------------------------------------------------
   To unsubscribe, e-mail: [hidden email]
   <mailto:[hidden email]>

   For additional commands, e-mail: [hidden email]
   <mailto:[hidden email]>




--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: slave.jar does not work

stephenconnolly
In reply to this post by Aleksandar Kostadinov
Another issue is if the connection originates from the slave, how does
the master know which slave the slave is supposed to be?

On Fri, Jul 11, 2008 at 7:59 AM, Aleksandar Kostadinov
<[hidden email]> wrote:

> Kohsuke Kawaguchi wrote, On 12/23/-28158 09:59 PM (EEST):
>> Stephen Connolly wrote:
>>> I wonder if he's trying to avoid adding a configuration for each
>>> slave  because the jnlp slave already provides this functionality (in
>>> essence)
>>
>> Right, but making JNLP work in a service management framework is
>> actually hard. You need some special tweak to make it headless, plus
>> logs don't go to stdout/stderr.
>>
>> I think it's much simpler if you just needed to daemonize a console
>> application.
>
> Right! I currently am unable to launch a windows slave through telnet or
> winexe because of line buffering. Not to talk black magic needed to go
> to that point. I hope such an implementation would consider security
> though as one wouldn't want to have a malicious slave attached to the
> master.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: slave.jar does not work

Kohsuke Kawaguchi
Administrator
In reply to this post by Aleksandar Kostadinov
Aleksandar Kostadinov wrote:

> Kohsuke Kawaguchi wrote, On 12/23/-28158 09:59 PM (EEST):
>> Stephen Connolly wrote:
>>> I wonder if he's trying to avoid adding a configuration for each
>>> slave  because the jnlp slave already provides this functionality (in
>>> essence)
>>
>> Right, but making JNLP work in a service management framework is
>> actually hard. You need some special tweak to make it headless, plus
>> logs don't go to stdout/stderr.
>>
>> I think it's much simpler if you just needed to daemonize a console
>> application.
>
> Right! I currently am unable to launch a windows slave through telnet or
> winexe because of line buffering. Not to talk black magic needed to go
> to that point. I hope such an implementation would consider security
> though as one wouldn't want to have a malicious slave attached to the
> master.
Good point. I guess we'd use a key file.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: slave.jar does not work

Kohsuke Kawaguchi
Administrator
In reply to this post by stephenconnolly
Stephen Connolly wrote:
> Another issue is if the connection originates from the slave, how does
> the master know which slave the slave is supposed to be?

I guess it would have to be launched like

   java -jar slave.jar http://server/hudson/ SLAVENAME


> On Fri, Jul 11, 2008 at 7:59 AM, Aleksandar Kostadinov
> <[hidden email]> wrote:
>> Kohsuke Kawaguchi wrote, On 12/23/-28158 09:59 PM (EEST):
>>> Stephen Connolly wrote:
>>>> I wonder if he's trying to avoid adding a configuration for each
>>>> slave  because the jnlp slave already provides this functionality (in
>>>> essence)
>>>
>>> Right, but making JNLP work in a service management framework is
>>> actually hard. You need some special tweak to make it headless, plus
>>> logs don't go to stdout/stderr.
>>>
>>> I think it's much simpler if you just needed to daemonize a console
>>> application.
>>
>> Right! I currently am unable to launch a windows slave through telnet or
>> winexe because of line buffering. Not to talk black magic needed to go
>> to that point. I hope such an implementation would consider security
>> though as one wouldn't want to have a malicious slave attached to the
>> master.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Loading...