PsExec hangs

I saw some old posts about PsExec issues related to its output.

I have an issue related to that:

In my msbuild file I have PsExec calls. I have one scenario that always hangs when it is being execute from teamcity agent,

but it is alwas successful when I run the msbuild from command line:

I am trying to delete a file on a remote machine, and the file is opened by notepad:

C:\Deployment\PsTools\PsExec /accepteula \\MyServer -u domain\administrator -p MyPassword cmd.exe /c del /S /F /Q "c:\MyFolder\*.*"

When a text file under Myfolder is open with notepad, the process just hangs.

I tried to redirect the output (using >nul), but it didn't help.

Any Idea? (excep using RemCom :))

12 comments
Comment actions Permalink

Hi

Yes, we had it reported several times before, but weren't able to find out the root cause.
Unfortunately I'm still not able to reproduce this issue in a lab.
Could you please post

  1. OS versions on TeamCity agent and remote machine
  2. a build log
  3. MSBuild's target


Thanks
Michael

0
Comment actions Permalink

Sorry, But I had a lot of issues with PsExec. Even when not running under Teamcity.

I switched to RemCom, and all issues are solved.

Thanks anyway,

Sagie

0
Comment actions Permalink

Well, That's a solution.

If anyone else meet such issue and would like to help us resolve it, please provide details:

  1. OS versions (with service pack) and editions (x86 or x64) on both TeamCity agent and remote machine.
  2. pstools version
  3. build step settings (including MSBuild target)
  4. a build log


Thanks

0
Comment actions Permalink

Hi,

I am having the same issues with PSexec from a TC build agent. Here are my details.

1. Windows Server 2003 R2, SP2
2. PsTools Version in this package: 2.44
3. It hangs on the uninstall commad

<exec program="${dir}\psexec" commandline='\\${server} msiexec /x {${msi.id}} /q' failonerror="false" />

4. Build log: (No Errors:)
[16:08:42]: deploy (running for 3m:57s)
[16:08:42]: [deploy] call (running for 3m:57s)
[16:08:42]: [call] uninstall.msi (running for 3m:57s)
[16:08:42]: [uninstall.msi] exec (running for 3m:57s)
[16:08:42]: [exec] PsExec v1.98 - Execute processes remotely
[16:08:42]: [exec] Copyright (C) 2001-2010 Mark Russinovich
[16:08:42]: [exec] Sysinternals - www.sysinternals.com

Hope this helps.
Keep me posted.
Thanks.

0
Comment actions Permalink

Hi Jerome

Unfortunately we still cannot reproduce this mysterious issue.

Could you confirm Windows versions please
- Is Windows Server 2003 R2 istalled on TeamCity agent machine?
- x86 or x64 edition?
- What version, service pack and bitness are on your ${server} machine?

- Is TeamCity agent running as a Windows service or interactivelly?
- Does it use bundled JRE, or external one? in second case - what version and bitness?

- Can you reproduce this behavior with command-line build runner?


That's a lot of questions, I know. But we really want to catch this issue.

Thank you.
Michael
0
Comment actions Permalink

Hi Michael,

Since Then I have set up a batch to execute nant via the command line without using TeamCity. Until recently I upgraded to TeamCity 6.5 in hope of this PSexec issue being resolved. It looks like this issue still exists. Below is the information you requested and hopefully it is useful.

BTW: Other CI tools like CrusieControl experiences the same problem with psexec. This may be because of both TC and CC are built using JAVA and there is some bug that causes this.


Thanks.

- Win server 2003 R2 is installed on the TC machine.

- x86

- ${server} has SP2 32-bit.

- Windows service

- Bundled JRE

- I can reproduce this using the command-line build runner. However the Thread dump showed that is hangs reading the psexec.exe file locally with the following error.

  • ·         Error -68. Failed to get thread dump from non-java process
  • This supports my suspicions about java and psexec.

    keep me posted if you guys found anything or there is a new version that fixes this.

    Thanks.

         

      0
      Comment actions Permalink

      Windows 7 Agent
      Windows 2008 R2 remote box, 64 bit OS

      Agent is running as a service on Win7 box
      Bundled JRE, I believe

      Running the exact same command from the command line executes flawlessly.  Locks up in Agent.

      Executable: psexec
      Command Line: -u [user] -p [pass] \\[machine] -i 1 -d "C:\Windows\System32\InstallLocal.bat"

      [13:28:24]Checking for changes

      [13:30:57]Publishing internal artifacts (1s)

      [13:30:58][Publishing internal artifacts] Sending build.start.properties.gz file

      [13:30:57]Clearing temporary directory: C:\BuildAgent\temp\buildTmp

      [13:30:57]Checkout directory: C:\BuildAgent\work\4fd1861e35a1bd68

      [13:31:01]Repository sources transferred

      [13:30:57]Updating sources: server side checkout (3s)

      [13:31:01]Resolving artifact dependencies (1m:07s)

      [13:32:08][Resolving artifact dependencies] 10 files retrieved for [**!**=>\Install] downloading pattern
      [13:32:09]Starting:  C:\Windows\system32\cmd.exe /c psexec -u xxx -p xxx  \\xxx -i 1 -d C:\Windows\System32\InstallLocal.bat
      [13:32:09]in directory: C:\BuildAgent\work\4fd1861e35a1bd68\Install

      [13:32:09]

      [13:32:09]PsExec v1.98 - Execute processes remotely

      [13:32:09]Copyright (C) 2001-2010 Mark Russinovich

      [13:32:09]Sysinternals - www.sysinternals.com

      [13:32:09]

      Hangs here indefinitely, even with Hang Detection on... sat for 1 hr before I terminated it.

      -Blayne Watt
      Senior Engineer
      General Electric

      0
      Comment actions Permalink

      The main problem for this hanging is because of the EULA prompt that PsExec does when running it for the first time. This was tested in both CruiseControl and TeamCity although TeamCity still acts up a little.

      Solution:

      - Make note of what account you are running the PsExec command as.(this will most like be the account running the buildagent. )

      - Make note of the server PsExec is trying to execute against for a particular command. example, uninstall, install etc.

      - RDP to that server using the account and password.

      - execute the same the PsExec command that usually hangs in TeamCity via command line.

      - This should prompt you with the License agreement (EULA).

      - Accept it

      - Once the command execute successfully, log off.

      - Go to TeamCity and this should work now.

      Problem: the steps outline above works perfectly for Crusie, but as for TeamCity it eventually goes back to its old behavior and hangs after couple of builds. I tried adding the -accepteula but it does not seem to help. One thing for sure the EULA is the problem.

      Hope this helps.

      Thanks,

      0
      Comment actions Permalink

      I have discovered that running the Agent in console mode executes PSExec properly, but if you are running your agent as a Service, psexec will hang.

      Fortunately, one of our agents (for smoketests) is already a console agent, so we've dedicated that box to the deployment for now, but I'd love to hear back on any improvements so I don't have to limit the build to 1 agent.

      regards,
      -Blayne Watt
      General Electric

      0
      Comment actions Permalink

      The EULA is only a problem if you're rolling back your VM and it's not been acknowledged.  We have psExec already installed and the eula has been acknowledged the mandatory first time.  As mentioned before, it works fine if I execute from a command line the same command.  The issue appears to be from an agent running as a service.

      -Blayne Watt
      General Electric

      0
      Comment actions Permalink

      The thing is that you execute PsExec under YOUR account where EULA is accepted.
      Build Agent is run under another user account where EULA is not accepted.

      You should manually run PsExec once ( this is true for all Sysinternal utilities ) under an account which is used to run Build Agent( for example using runas commnad )

      0
      Comment actions Permalink

      Interesting.  Thanks for the information, Vasily.  Much appreciated.

      -B

      0

      Please sign in to leave a comment.