| You are viewing documentation of TeamCity 4.x, which is not the most recent released version of TeamCity. Please refer to the listing to choose another version. |
|
If you experience problems running TeamCity and believe it's related to the software, please contact us with detailed description of the issue. To fix a problem, we may need a wide range of information about your system as well as various logs. The section below explains how to collect such information. In this section: Logging EventsTeamCity (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. Before reproducing the problem it makes sense to enable 'DEBUG' log level for TeamCity classes. To do it, edit the logs/teamcity-(server|agent)-log4j.xml file by removing all the lines containing <!--DELETE THIS LINE FOR ENABLING DEBUG LOGGING--> comment. Make sure the logs are rotated by default. 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 DumpsIf you experience problems with the TeamCity server or agent (e.g. no responding or working too slow) we would appreciate a thread dump of the process. First, please indicate what process you need a thread dump for. If there is an issue with the server or build sources checkout issue, you will need a thread dump of the web server process (e.g. Tomcat), if the issue is related only to a single build, you will need an agent thread dump. If you need agent thread dump, please note that TeamCity agent consists of two java processes: launcher and agent itself. Agent is run by the launcher process. You will usually be interested in the agent (more nested one) and not the launcher process. To take a thread dump:
Under Linux
You can also use third-party GUI tool: AdaptJ StackTrace Utility. See also Server Performance section below. OutOfMemory ProblemsIf you experience problems with TeamCity "eating" too much memory (OutOfMemory errors), please do the following:
Version Control Debug LoggingIn general, to debug VCS-related problems we need information for jetbrains.buildServer.VCS Log4j category. So please enable it in the <TeamCity home>\conf\teamcity-server-log4j.xml (for server-side checkout) and <BuildAgent home>\conf\teamcity-agent-log4j.xml (for agent-side checkout) files: There is a set of debug options that turn on debug logging for specific version controls. If the version control you use is mentined below, 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. Subversion Integration Debug LoggingFirst, please enable generic VCS debug logging, as described above. Adjust the logging configuration and restart the server or agent, correspondingly. The log will be saved to the logs/teamcity-svn.log file. Generic VCS log should be also taken from logs/teamcity-vcs.log ServerTo turn on debug logging of the SVNkit library on the server side, uncomment all the lines marked with <!- AgentTo turn on debug logging of the SVNkit library on the agent (only relevant for agent-side checkout mode) uncomment the following lines in the CVSFor versions prior to TeamCity 4.0: For latter versions it is enough to enable debug logging. ClearCaseUncomment Clearcase-related lines in the <TeamCity home>\conf\teamcity-server-log4j.xml file. Patch Application ProblemsIn case server-side checkout is used, the "patch" that is passed from server to the agent can be retrieved by:
Agent log will contain the line "Patch is saved to file ${file.name}" Remote Run ProblemsThe 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). Server PerformanceIf 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. Logging in TeamCity Visual Studio pluginTo capture logs from TeamCity Visual Studio plugin please do the following:
Logging in TeamCity Eclipse pluginAvailable only since TeamCity 4.5 To enable tracing for the plugin, run Eclipse IDE with the -debug <filename> program argument. The <filename> portion of the program argument is a properties file containing key-value pairs. Name of each property corresponds to the plugin module and value is either 'true' (to enable debug) or 'false'. Here is an example of enabling most common tracing options: Read more about Eclipse Debug mode Gathering Information About Your Plug-in and built-in Eclipse help. Sending Information to the DevelopersFiles under 5Mb in size can be attached right into the tracker issue (if you do not want the attachments to be publicly accessible, limit viewing the attachment to "teamcity-developers" user group only). If 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. If you receive permission denied error on upload attempt, please rename the file. You can also send small files via email: teamcity-feedback@jetbrains.com Please do not forget to mention your TeamCity version and environment |