GET suddenly started failing sporadically

stingray · Post by **stingray** » Fri Aug 24, 2007 12:43 pm

Vault client is version 3.5.1.4786
Vault server is version 3.5.1.4786
---------------------------------------
Good afternoon,

I've scoured the forums and haven't seen the specific problem we're having, so I'm posting.

We're building each night in batch using VisualBuildPro 6. Suddenly over the weekend, some GETs started failing. Not all, just some.

Here's a GET that works:
"C:\Program Files\SourceGear\Vault Client\vault.exe" -host HOSTNAME -user USER -password PASSWORD -repository REPOSITORY get $/DevTools/Project -makewritable -setfiletime current -merge overwrite -exclusive -backup no

This one fails:
"C:\Documents and Settings\build>"C:\Program Files\SourceGear\Vault Client\vault.exe" -host HOST -user USER -password PASSWORD -repository REPOSITORY get $/Trunk/Project -makewritable -setfiletime current -merge overwrite -exclusive -backup no -performdeletions removeworkingcopy
*but* this one worked up until last weekend.

Troubleshooting steps so far:
- Tried the same GETs in command line, and they failed there too. Others work, though, oddly enough.

- Manually running the same build script directly through VBP works, but when executed through batch fails at the GET--sometimes.

- Client login information hasn't changed. No software patches have been made. It just all of a sudden randomly stopped working at different points in the build.

- The batch and command-line are using the same user login both on the local build machine.

- Default/working directories have been specified in Vault through the GUI client.

- A command line LISTWORKINGFOLDERS from the build machine correctly shows the proper working directories.

At this point we're stymied. Any clues would be appreciated.

lbauer · Post by **lbauer** » Fri Aug 24, 2007 3:23 pm

Any information in the Vault Server log that co-incides with the failure?

It's sgvaul in %windir%\temp\sgvault on the Vault server machine.

Can you do the get with the Vault GUI Client?

Has anything changed in your network settings?

Anything different about the files you can get and those you can't -- file size, extension, etc.?

stingray · Post by **stingray** » Mon Aug 27, 2007 5:43 am

Any information in the Vault Server log that co-incides with the failure?

It's sgvaul in %windir%\temp\sgvault on the Vault server machine.

Can you do the get with the Vault GUI Client?

Has anything changed in your network settings?

Anything different about the files you can get and those you can't -- file size, extension, etc.?

No to #1.

Yes to #2.

No to #3.

No to #4.

lbauer · Post by **lbauer** » Mon Aug 27, 2007 7:52 am

Are there any error messages when you try to do the get with the command line client? I think you can use -verbose to get more information

In the command you posted that failed, can you run it without this parameter?

-performdeletions removeworkingcopy

stingray · Post by **stingray** » Mon Aug 27, 2007 7:59 am

Are there any error messages when you try to do the get with the command line client? I think you can use -verbose to get more information

In the command you posted that failed, can you run it without this parameter?

-performdeletions removeworkingcopy

Haven't tried with -verbose. I will do that and report back.

We tried running the command w/out the parameters and it didn't make any difference.

BTW, I'm running a batch build now and it is working, as reported earlier. The *only* difference is that I manually initiated the build from a VB app rather than a scheduled batch job. But the exact same build scripts are being run in both cases.

It seems that the entry point into the build scripts is somehow wigging out Vault??

ian_sg · Post by **ian_sg** » Mon Aug 27, 2007 8:33 am

Be sure the scheduled job is running under an appropriate Windows user account.

stingray · Post by **stingray** » Mon Aug 27, 2007 8:45 am

I'm sure it is, but I'll double-check.

stingray · Post by **stingray** » Mon Aug 27, 2007 9:19 am

stingray wrote:I'm sure it is, but I'll double-check.

Confirmed the account is a valid Windows account. This account hasn't changed in years.

Next thoughts?

ian_sg · Post by **ian_sg** » Mon Aug 27, 2007 9:21 am

How about the rights on that account? For troubleshooting purposes, I'd set the job to run as the same user from which you initiate it manually. If that works, you know you've got a Windows permissions issue.

stingray · Post by **stingray** » Mon Aug 27, 2007 9:27 am

ian_sg wrote:How about the rights on that account? For troubleshooting purposes, I'd set the job to run as the same user from which you initiate it manually. If that works, you know you've got a Windows permissions issue.

They are the same account. We login to the build machine with the same user account that the nightly batch build job is running with.

stingray · Post by **stingray** » Tue Aug 28, 2007 7:59 am

lbauer wrote:Are there any error messages when you try to do the get with the command line client? I think you can use -verbose to get more information

In the command you posted that failed, can you run it without this parameter?

-performdeletions removeworkingcopy

Linda,

I didn't see the VERBOSE option in vault.exe HELP. Am I missing something?

lbauer · Post by **lbauer** » Tue Aug 28, 2007 8:33 am

It's not listed separately. It's an option for many commands. For example if you type "vault help get" it's one of the options for get. You need hypen in front of it:

Code: Select all

-verbose

stingray · Post by **stingray** » Wed Aug 29, 2007 12:07 pm

-verbose didn't reveal anything unusual from commandline.

I added it to tonight's run of the builds to see if I get a different result. I'll report back tomorrow.

stingray · Post by **stingray** » Thu Aug 30, 2007 6:06 am

The automated batch build worked last night. We're bewildered but happy.

We're not sure precisely why it started working. The one thing that comes to mind is that we had a power outage over the weekend so the build machine was rebooted. Wouldn't be the first time that fixed something!

Anyway, don't spend any more time on this.

Thanks for the ideas.