TeamCity cannot start

We use TeamCity at work as our Continuous Integration server. It’s a very useful tool. This morning it wasn’t running because of a sys admin change. Most of our servers are virtual machines and the change was to do with configuring the SCSI. I’m not quite certain why the change was made but it involved a re-start to the servers.

Now, as far as I’m concerned a re-start to the server shouldn’t have caused problems but of course sometimes it does. One of the reasons why is that settings are altered every so often and re-starting a server causes some of these changes to be re-set or for default settings to start.

I access TeamCity via a URL and when I found I couldn’t my first thoughts were that the service wasn’t running on the server. I logged onto the server but the services were running. Checking the log files for TeamCity told me that ‘something’ was using port 80, which TeamCity needed to use. I also checked the firewalls just in case any of the them had reset and were now blocking access. TeamCity accesses a remote database.

The steps we took at work to solve this were as follows.

  1. We read the logs this told us that it TeamCity could not use port 80.
  2. We looked at Task Manager, then Resource Monitor (the server is Windows 2008 R2) where we could see that ‘something’ with process ID 4 was using port 80.
  3. We downloaded ProcessExplorer to find that it was the ‘NT Kernel & System’ that was using port 80, although we could have used Task Manager to tell us this, we just needed to altered the view to show process ids.
  4. We then read this really good article about “NT Kernel & System using Port 80”¬†this told us that we needed to disable the Web Deployment Agent Service. This was the culprit using port 80.

Note, I say we since Richard at work helped me a lot to solve this. I’m a touch disappointed with myself since I guessed what had happened, the server restart had caused something to reset but I hadn’t found what had done it. I sometimes have a blinked approach where I stare at one thing wondering why I can’t find what is wrong. What is often needed is to step back and look again with fresh eyes.

All this is experience though and I’m writing it down so I’ve got something to refer back to. Hope this helps someone else too.

This is the article that Luke Browning wrote that helped me.

NT Kernel & System using Port 80
I had been trying to set up Internet Information Services (IIS) under Windows 7 to use PHP and MySQL to save myself the trouble of having both IIS and XAMPP installed. After a short time I managed to get it running rather easily using the Web Platform Installer. This was great apart from a couple of small annoyances when developing PHP applications. After a few weeks of use, I decided it was about time to switch back to XAMPP as it removed all of the annoyances I had encountered – here, I ran into a couple of problems!

IIS Removal
I began by uninstalling IIS from the “Turn Windows features on or off” dialog in “Programs and Features”. This seemed to go fine and about a minute later I was rebooting my system.

Once my system had rebooted, I began the installation of XAMPP and got right to the end where it mentioned apache could not start. I thought this must be due to having some other peice of software bound to port 80, e.g. IIS didn’t uninstall correctly or Skype was running – neither of which were the case. I downloaded a tool called TCPView which allows me to see all of the connections from my machine and which application they originate from. I found the http protocal that was listening on the local port (being port 80) belonged to System (PID 4).

Upon looking up this process in Task Manager, I found it to be the “NT Kernel & System” which immedietly made me assume it was an incomplete removal of IIS. I tried reinstalling and removing IIS, uninstalling all of the related web tools such as the Web Platform Installer, IIS Redirects and finally rebooting the system a couple of times. None of these methods fixed the problem and Google searches were not finding any useful information.

The Solution
It appears there are a couple of different applications that can cause this same problem;

1.IIS is still running.
2.SQL Server Reporting Services is running.
3.Web Deployment Agent Service is running (this was my problem).
To fix my issue (number 3), I followed the following procedure:

1.Open up the services screen (Right click “Computer” from either your desktop or start menu, then “Manage”. Once the window has opened, expand “Services and Applications” and select “Services”).
2.On the services screen there should be one called “Web Deployment Agent Service”, if this is running, double click it and stop the service.
3.Finally, change the startup type to “Disabled”.
Now if you try to run apache on port 80, it should start fine!

Migrating TeamCity from its internal database

When I first installed TeamCity, a continuous integration tool from JetBrains, I went with its default setup, which uses its internal database to keep track of builds and so on. TeamCity displays a warning that the internal database should only be used for evaluation and that if using TeamCity for production purposes it highly recommends using an external database.

This is a task that’s needed doing for a while but I’ve not really been looking forward to it. Finally, today I bit the bullet, grasped the nettle, and every other cliche (and like the readers of this sentence are wishing) got on with it!

As we’ve been using TeamCity now for five months there is quite a bit of data that I didn’t want to lose so I wanted to migrate the data. The instructions are quite detailed and I feel can cause a bit of confusion but basically there are three steps to follow.

  1. Create an external database. For me this was Microsoft SQL server, version 2008 R2. In Management Studio I created a new database called TeamCity and a new login. I right-clicked on the new login, selected properties and mapped the user to this new database.
  2. I then downloaded the native driver for SQL Server for TeamCity to use. I got the MS sqljdbc package from Microsoft. The extension said it was an exe but it is a zip file. Un-packing it I put the sqljdbc.jar into the correct folder following the TeamCity instructions
  3. Then again following the instructions I created a database.properties file putting in the appropriate values. Make sure you look closely at the typing since I had some problems running the maintainDB tool when it couldn’t find the correct driver.
  4. Shut the teamcity service down.
  5. I then needed to run the maintainDB tool to move data into the new database. I had some problems here. The instructions explicitly state that you only need to specify two arguments: -A and -T. However, you also need to specify the source. Thankfully I found this post and the excellent comments by my namesake . Once I specified the three arguments then I could run maintainDB with no problems.
  6. Re-start the TeamCity service and see it pick up the new settings.

I suspect that a few more times doing this and it won’t feel so daunting.

 

Moving Repositories from one SVN server to another

I recently set up a new SVN server at work and today we moved one of our projects from the old SVN server to this new one. We use VisualSVN on both.

To do this you need to first create a dump file on the old server then copy the dump file to the new server and load that up. This is done via the svnadmin executable.

These are the steps I followed.

  1. Log on to the old server and open up a command prompt.
  2. In the command prompt navigate to the bin folder where the svnadmin exe is found.
  3. Run this command svnadmin dump path/to/repository > repositoryname.dmp. For example: svnadmin dump C:/Repositories/TestProject > C:/TestProject.dmp
  4. Make sure that you are pointing to where the repositories actually are. I initially tried using the URLs and that doesn’t work.
  5. Log on to the new server and copy the DMP file across
  6. Open a command prompt and navigate to the bin folder where the svnadmin exe is found
  7. Run this command svnadmin load path/to/repository < repositoryname.dmp. For example: svadmin load E:/Repositories/NewProject < C:/TestProject.dmp
  8. I had some problems trying to get this to write into a new empty repository. The problem was I’d created a new repository that contained the default structure: branches, tags and trunk. When I created a new repository without this default structure then it worked OK.

I’m writing this up and hoping that if I ever have to do it again then these notes might help. If they help someone else as well that would be great too.