[JIRA] Created: (HUDSON-6379) Unable to tag CVS projects when job is built on slave

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[JIRA] Created: (HUDSON-6379) Unable to tag CVS projects when job is built on slave

Hudson issues mailing list
Unable to tag CVS projects when job is built on slave
-----------------------------------------------------

                 Key: HUDSON-6379
                 URL: http://issues.hudson-ci.org/browse/HUDSON-6379
             Project: Hudson
          Issue Type: Bug
          Components: cvs-tag
    Affects Versions: current
         Environment: Hudson master is v1.355 running within Tomcat container on Sun JDK6 / Red Hat Enterprise Linux Server release 5.4 (Tikanga)
Problem is reproducible on two different slaves:
Slave 1 is another RHEL5 machine, which the master connects to via SSH
Slave 2 is a Windows XP machine, which the master connects to via Cygwin SSH.
            Reporter: msbcode


When a slave build is successful, the CVS tagging step fails with an error that looks like:

Executing tag command: cvs -d :ext:username@cvs-server:/cvsroot/modulename rtag -D "2010-04-27 11:25" ProjectName-15-2010_04_27 modulename
[hudson6778661643085967450tmp] $ cvs -d :ext:samuel@cvs-server:/cvsroot/modulename rtag -D "2010-04-27 11:25" ProjectName-15-2010_04_27 modulename
ERROR: Cannot run program "cvs" (in directory "/usr/java/hudson-tomcat/temp/hudson6778661643085967450tmp"): java.io.IOException: error=2, No such file or directory
java.io.IOException: Cannot run program "cvs" (in directory "/usr/java/hudson-tomcat/temp/hudson6778661643085967450tmp"): java.io.IOException: error=2, No such file or directory
        at java.lang.ProcessBuilder.start(ProcessBuilder.java:474)
        at hudson.Proc$LocalProc.<init>(Proc.java:149)
        at hudson.Proc$LocalProc.<init>(Proc.java:121)
        at hudson.Launcher$LocalLauncher.launch(Launcher.java:636)
        at hudson.Launcher$ProcStarter.start(Launcher.java:271)
        at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:783)
        at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:757)
        at hudson.remoting.UserRequest.perform(UserRequest.java:114)
        at hudson.remoting.UserRequest.perform(UserRequest.java:48)
        at hudson.remoting.Request$2.run(Request.java:270)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
        at java.util.concurrent.FutureTask.run(FutureTask.java:166)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:636)
Caused by: java.io.IOException: java.io.IOException: error=2, No such file or directory
        at java.lang.UNIXProcess.<init>(UNIXProcess.java:164)
        at java.lang.ProcessImpl.start(ProcessImpl.java:81)
        at java.lang.ProcessBuilder.start(ProcessBuilder.java:467)

This problem is reproducible on two different slave machines of ours, one which has RH enterprise 5 and the other which is a Windows XP slave. The exception for jobs that use the Windows slave has a slightly different stacktrace, but with the same error message.

My un-educated guess is that after the build is completed on the slave, the cvs tag command ("cvs .. rtag ..") is being executed on the master itself and not on the slave, where the workspace folder actually exists. This is my theory since the path in the failed command contains "/usr/java/hudson-tomcat", which is the location of the Tomcat 6 instance hosting our Hudson install.

We first noticed this issue when our master server was using version 1.334. We upgraded to v1.355 to see if this was a bug that has been fixed, but it was not.
   
The expected behavior for us would be that the CVS tag command is executed on/by the slave machine, since that is where the workspace folder is.
   

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.hudson-ci.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

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

Reply | Threaded
Open this post in threaded view
|

[JIRA] Updated: (HUDSON-6379) Unable to tag CVS projects when job is built on slave

Hudson issues mailing list

     [ http://issues.hudson-ci.org/browse/HUDSON-6379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

burghduffkc updated HUDSON-6379:
--------------------------------

    Attachment: CvsTagPlugin-Patch.java

The attached patch fixes the problem with using the cvs-tag on remote slaves.  We have been running with the patched code for about two weeks and have not seen any issues.  The master and slaves are windows machines.

> Unable to tag CVS projects when job is built on slave
> -----------------------------------------------------
>
>                 Key: HUDSON-6379
>                 URL: http://issues.hudson-ci.org/browse/HUDSON-6379
>             Project: Hudson
>          Issue Type: Bug
>          Components: cvs-tag
>    Affects Versions: current
>         Environment: Hudson master is v1.355 running within Tomcat container on Sun JDK6 / Red Hat Enterprise Linux Server release 5.4 (Tikanga)
> Problem is reproducible on two different slaves:
> Slave 1 is another RHEL5 machine, which the master connects to via SSH
> Slave 2 is a Windows XP machine, which the master connects to via Cygwin SSH.
>            Reporter: msbcode
>         Attachments: CvsTagPlugin-Patch.java
>
>
> When a slave build is successful, the CVS tagging step fails with an error that looks like:
> Executing tag command: cvs -d :ext:username@cvs-server:/cvsroot/modulename rtag -D "2010-04-27 11:25" ProjectName-15-2010_04_27 modulename
> [hudson6778661643085967450tmp] $ cvs -d :ext:samuel@cvs-server:/cvsroot/modulename rtag -D "2010-04-27 11:25" ProjectName-15-2010_04_27 modulename
> ERROR: Cannot run program "cvs" (in directory "/usr/java/hudson-tomcat/temp/hudson6778661643085967450tmp"): java.io.IOException: error=2, No such file or directory
> java.io.IOException: Cannot run program "cvs" (in directory "/usr/java/hudson-tomcat/temp/hudson6778661643085967450tmp"): java.io.IOException: error=2, No such file or directory
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:474)
> at hudson.Proc$LocalProc.<init>(Proc.java:149)
> at hudson.Proc$LocalProc.<init>(Proc.java:121)
> at hudson.Launcher$LocalLauncher.launch(Launcher.java:636)
> at hudson.Launcher$ProcStarter.start(Launcher.java:271)
> at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:783)
> at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:757)
> at hudson.remoting.UserRequest.perform(UserRequest.java:114)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:270)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:636)
> Caused by: java.io.IOException: java.io.IOException: error=2, No such file or directory
> at java.lang.UNIXProcess.<init>(UNIXProcess.java:164)
> at java.lang.ProcessImpl.start(ProcessImpl.java:81)
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:467)
> This problem is reproducible on two different slave machines of ours, one which has RH enterprise 5 and the other which is a Windows XP slave. The exception for jobs that use the Windows slave has a slightly different stacktrace, but with the same error message.
> My un-educated guess is that after the build is completed on the slave, the cvs tag command ("cvs .. rtag ..") is being executed on the master itself and not on the slave, where the workspace folder actually exists. This is my theory since the path in the failed command contains "/usr/java/hudson-tomcat", which is the location of the Tomcat 6 instance hosting our Hudson install.
> We first noticed this issue when our master server was using version 1.334. We upgraded to v1.355 to see if this was a bug that has been fixed, but it was not.
>    
> The expected behavior for us would be that the CVS tag command is executed on/by the slave machine, since that is where the workspace folder is.
>    

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.hudson-ci.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

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