Reporting Issues

If you experience problems running TeamCity and believe it's related to the software, please contact us with detailed description of the issue.
You can post an issue into publicly available issue tracker.
Or write us an e-mail

To fix a problem, we may need a wide range of information about your system and various logs. The information below will help explain how to collect this information from your system when you are having trouble.

In this section:

• Logging
• Hangs and thread dumps
• OutOfMemory problems
• Version Control Debug Logging
• Patch Application Problems
• Remote Run Problems
• Server Performance
• Sending Large Files to the Developers

Logging

TeamCity (both server and build agents) logs events and warnings using log4j.

The logging rules and log4j configuration files for TeamCity are described in Logs of Internal Events.

By default, log4J configuration file is <TeamCity home>/conf/teamcity-server-log4j.xml for the server, and <agent home>/conf/teamcity-agent-log4j.xml for build agents. These default settings are used if TeamCity server is installed from Windows distributions or is run by runAll startup script. If you start the web server using your own script make sure you pass -Dlog4j.configuration=file:../conf/teamcity-server-log4j.xml -Dteamcity_logs=../logs/ JVM options.

Before reproducing the problem it makes sense to enable 'DEBUG' log level for TeamCity classes. To do it, change the following section in teamcity-(server|agent)-log4j.xml files:

After that, DEBUG messages will go to teamcity-*.log files.

There are also more specific logs that can be enabled by removing comments in the file (marked with <!-UNCOMMENT FOR DEBUG-> string).

Make sure the logs are not rotate too quickly. When debug is enabled it makes sense to increase maxBackupIndex value in the relevant appender tag to 10 or even 20 files (ensure there is sufficient free disk space available)

You can change the log4J configuration files while the server/agent is running. If it is possible (some log4j restrictions apply), the loggers will be reconfigured without process restart.

Hangs and thread dumps

If you experience problems with the TeamCity server (e.g. no responding or working too slow) we would appreciate a thread dump of the server process.

• On Windows, press Ctrl+Break in console window.
• On Linux, run 'jstack <pid_of_java_process>' or 'kill -3 <pid_of_java_process>'. Output will appear in <TeamCity home>/logs/catalina.out.

In GUI mode, you can also use AdaptJ StackTrace Utility under Windows, Linux or Mac OS X to get the stacktrace of the process even if it runs without console.

See also Server Performance section below.

OutOfMemory problems

If you experience problems with TeamCity "eating" too much memory (OutOfMemory errors), please do the following:

• determine what process encounters the error (the actual building process, the TeamCity server, or the TeamCity agent)
• try to increase the memory for the process via '-Xmx' JVM option, like -Xmx512m. The option needs to be passed to the process with problems:
  • if it is the building process itself, use "JVM Command Line Parameters" settings in the build runner. e.g. Inspections builds may specifically need to increase the parameter;
  • if it is TeamCity server, modify runAll.* script or (if server is run as Windows service), use TeamCity/bin/tomcat6w.exe //ES//TeamCity (see more);
  • if it is TeamCity build agent, modify agent.* script
• if increasing memory does not help, please get the memory dump and send it to us for further analysis:
  • to get a memory dump (hprof file) when an OOM error occurs, please add the following JVM option (works for JDK 1.5.0_07+): -XX:+HeapDumpOnOutOfMemoryError
  • when OOM error occurs next time, java_xxx.hprof file will be created in the process startup directory (TeamCity/bin or buildAgent/bin);
  • please archive the file and send it to us.

Version Control Debug Logging

There are a set of debug options that turn on debug logging for specific version controls. Run the server with the required option and send us teamcity-vcs.log file for analysis. Some version controls also have specific logs that appear after uncommenting corresponding sections form the log4j configuration file.

Some options need to be specified as JVM parameters. For description of more JVM parameters and how to add them see System Properties for Running the Server section.

SVN Debug Logging

Adjust the logging configuration and restart the server or agent, correspondingly.
The log will be saved to the logs\teamcity-svn.log file.

Server

To turn on debug logging of the SVNkit library on the server side, uncomment the lines marked with <!-UNCOMMENT FOR DEBUG-> in the <TeamCity home>\conf\teamcity-server-log4j.xml file.
In TeamCity version prior to 3.1, follow the instructions to enabling debug on agent, but in <TeamCity home>\conf\teamcity-server-log4j.xml file.

Agent

To turn on debug logging of the SVNkit library on the agent (only relevant for agent-side checkout mode) uncomment the following lines in the
<agent home>\conf\teamcity-agent-log4j.xml file:

CVS

Add -Dcvs.log.commands=true JVM parameter to the server and also to the agent (for agent-side checkout only). The logging will go into logs/teamcity-vcs.log.

ClearCase

Use -Dcc.log.commands=true JVM parameter
ClearCase commands with their output will be stored into ClearCase.log file in the server working directory.

Patch Application Problems

In case server-side checkout is used, the "patch" that is passed from server to the agent can be retrieved by:

• add property agent.save.patch=true to the build configuration properties: Administration->Edit configuration->Properties and requirement variables->Add new property...
• trigger the build.

Agent log will contain the line "Patch is saved to file ${file.name}"
Get the file and provide it with the problem description.

Remote Run Problems

The changes that are sent form the IDE to the server on a remote run can be retrieved from server's .BuildServer\system\changes directory. Locate the <change_number>.changes file that corresponds to your change (you can pick the latest number available or deduce the from the URL of the change form the web UI).
The file contains the patch in the binary form. Please provide it with the problem description.

Server Performance

If you experience degraded server performance and TeamCity server process is producing large CPU load, please take the CPU profiling snapshot and send it to us accompanied with the detailed description of what you were doing and what is your system setup.

You can take the CPU profiling and memory snapshots by installing the server profiling plugin and following the instructions provided on the plugin page.

Logging in TeamCity Visual Studio plugin

To capture logs from TeamCity Visual Studio plugin please do the following:

1. Close all instances of Visual Studio
2. Open <username-profile-folder>\Local Settings\Temp\JetLogs folder
3. Delete all of the files in this folder
4. Restart Visual Studio
5. Open a solution
6. Try to log in to TeamCity
7. Close Visual Studio
8. Navigate back to the <username-profile-folder>\Local Settings\Temp\JetLogs folder. All of the files that were created are logs.

Sending Large Files to the Developers

Files under 5Mb in size can be attached right into the tracker issue.
If you do not want the content of the files be publicly available or the file is over 5 Mb, you can upload the archived files to ftp://ftp.intellij.net/.uploads and let us know the exact file name.