views:

479

answers:

3

We use TeamCity, nant and psexec to run a command on a remote machine as part of the release packaging. Everything works fine when I run the nant from the console but when running from teamcity psexec hangs (freezes) 50% of the times.
I looked through many forums and there seems to be workarounds that increase complexity of the call and involve loosing the output and the errorcode of the command.
Does anyone know an easier way to run a command on a remote machine?
I don't mind setting up some application on the remote machine, like a telnet server, any advices on what to do?
Thanks

+1  A: 

How about putting a (nant) time-out on the psexec and repeat the call until no time-out happens?

Regards,

Sebastiaan

Sebastiaan Megens
Hmm, as quick workaround it's a good ideia. :) I'll try that.
Paulo Manuel Santos
That was quite easy to do! used the <exec> timeout and checked for error level = -1000, then put 5 calls to the target in a row with <if>'s. If nothing better comes up I'll keep this!
Paulo Manuel Santos
Good to hear. :)Can't you use foreach? That way your script will be bit cleaner.Regards,Sebastiaan
Sebastiaan Megens
+1  A: 

I have solved this issue with a combination of RemCom and a custom MSBuild task called ExecParse.

RemCom, because it doesn't do odd things with STDOUT (thus hanging the build). We used, and ExecParse to capture the output of the remote task, and parse the Exit Code from the output, because the standard MSBuild Exec task does not capture output. Some NAnt equivalent that captures the output would work.

I've detailed this in a blog post: "Continuous Integration: Executing Remote Tasks with TeamCity, MSBuild, RemCom, and ExecParse"

Will Green
RemCom worked! I couln't get the STDOUT and STDERR from the command outputing from nant, but I could parse the exit code by saving the exec output to a file and then using a regex to parse the file. Thank!
Paulo Manuel Santos
A: 

I use PSExec with the -d option (don't wait for it to finish) and capture the return code. The return code when you used -d is the process ID of the process running on the remote system. then I use PSList to poll the remote system for the process ID until I don't find it on the remote system any longer.

JimM
If that always works it may be good. But it seems to me you can't get the return code like that, do you use some other way of knowing how it finished?
Paulo Manuel Santos