SVN connection works once after service restart, fails subsequently.

Our 8.1.3 build of TeamCity has been stable and untouched since upgrading a few months back.

It has started to play up now and the only way to get it working again is to restart the TC Windows Service.

The exact error is:
Failed for the root 'svn://' #10: svn: E210003: connection refused by the server

Connections from this server to SVN using the same account (at the same time as the error) still work via TortoiseSVN.

Restarting TC service gets it to run successfully once more, then it fails again.

I've recreated the VCS root to no avail.

It seems as if something is left in an odd state by the service and not cleaned up after the initial connection, my guess is an open socket to SVN.

Can anyone point me in the right direction? Server is Windows 2012, TC installed as an agent. Other projects carry on working (to different repos).

Comment actions Permalink


Both TC server and TC agent should have access to repository, have you checked that connection to SVN works properly from TC server machine?
Could you please attach teamcity-vcs.log?

Comment actions Permalink


Yes, the connection works from TortoiseSVN from the same machine and will work ONCE when the TC service is restarted. I think this proves the connectivity is OK.

The complete (build) log output is;

[15:53:46]Checking for changes

[15:54:07]Failed to collect changes, error: svn: E210003: connection refused by the server

[15:54:07]Build finished

I know it says connection refused, but a restart of the service fixes this for one shot and at the same time, TortoiseSVN from the same box still works.

So it is not limited by IP address or login (both the same), I suspect that the error is false or that it has left a socket handle open and fails internally to re-use it.
Comment actions Permalink


Can you please turn on debug-vcs mode as described here and provide us with teamcity-vcs.log file?

Comment actions Permalink

Thanks for being patient Alina.

Following steps taken;

  1. Service stopped.
  2. Backed up and moved log directory contents.
  3. Service started.
  4. debug-vcs set
  5. Number of builds attempted, first build works.
  6. Start 2nd build, errors.

Log file is attached, I've obfuscated the logins and project names. I can send the original if required.

Comment actions Permalink

Hello Ryan,

   It looks like that for successful builds TeamCity doesn't try to perform "collect changes" operation and runs the build on the current revisions.
   When it tries to connect VCS server, it fails.

   Could you please try "Test connection" operation on the VCS Root page - does it work?
   What kind of authentication and what kind of SVN server you're using?

   Kind regards,

Comment actions Permalink

Hi Kirill,

Test Connection works fine.

I'm using the standard SVN server authentication, I've not done anything special. Sorry, I don't know what scheme it is, just out of the box.

I did notice that the VM I am running this on installed another network card the other day. It might be possible that there is a binding to an old outbound network card that is disabled.

A restart of the service just caused it to grab the latest changes again and it did connect, just does not afterwards.

I think I may have to reinstall TC. This was running for some time and working fine with no apparent changes, the only thing that could have changed is the VM environment and I think it is related to the network card as I see no other changes.

Happy to send more detailed logs if you need them.

Comment actions Permalink

Hello Ryan,

  I'm sorry for delay with the answer.

  Unfortunately, so far I'm not sure what could have caused the trouble. The exception in the log indicates that there was a timeout connecting the server.
  Could you possibly increase the connect timeout from the default 60 seconds to, say 180 seconds? To do this, add <TeamCityDataDirectory>/config/ file with the contents like

  Also, when TeamCity fails to run the build - do "Test connection" work in this situation?

  I'm pretty sure that we don't have non-closed stale connections in our code which could cause such an issue.

  If all this won't help, I'd appreciate if you create an issue in our tracker at, and provide related information.



Please sign in to leave a comment.