I think you could be right. I just ran it as ccnet.exe as myself and no problem. However I just put it back to being a service and set a build to trigger automatically and it also worked fine, consistantly. Just going to leave it for now and see if it breaks. If not then I am very confused what was even wrong.
When stopping the service after it has done atleast one build I get the following messages. Windows could not stop the CruiseControl.NET Server service on CRUISECTRL. The service dot not return an error. This could be an internal Windows error or an internal service error. If the problem persists, contact your administrator. The service didn't stop. So I tried again and got below. Windows could not stop the CruiseControl.NET Server service on CRUISECTRL. Error 1061: The service cannot accept control messages at this time. 2009/7/3 Ruben Willems <[email protected]>: > Hi > > sounds like a securoty issue > can you set the C:\Program Files\CollabNet Subversion Client folder > with everyone full control (just as a test) > > > with kind regards > Ruben Willems > > On Fri, Jul 3, 2009 at 11:34 AM, Adam Burton <[email protected]> wrote: >> >> Yes, running it as a service under an account which has administrator >> priviledges on the server. >> >> System.IO.IOException: Unable to execute file [C:\Program >> Files\CollabNet Subversion Client\svn.exe]. The file may not exist or >> may not be executable. ---> System.ComponentModel.Win32Exception: The >> system cannot find the path specified at >> System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo >> startInfo) at System.Diagnostics.Process.Start() at >> >> ThoughtWorks.CruiseControl.Core.Util.ProcessExecutor.RunnableProcess.StartProcess() >> --- End of inner exception stack trace --- at >> >> ThoughtWorks.CruiseControl.Core.Util.ProcessExecutor.RunnableProcess.StartProcess() >> at >> ThoughtWorks.CruiseControl.Core.Util.ProcessExecutor.RunnableProcess.Run() >> at >> ThoughtWorks.CruiseControl.Core.Util.ProcessExecutor.Execute(ProcessInfo >> processInfo) at >> >> ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.Execute(ProcessInfo >> processInfo) at >> >> ThoughtWorks.CruiseControl.Core.Sourcecontrol.Svn.GetModifications(IIntegrationResult >> from, IIntegrationResult to) at >> >> ThoughtWorks.CruiseControl.Core.Sourcecontrol.QuietPeriod.GetModifications(ISourceControl >> sourceControl, IIntegrationResult lastBuild, IIntegrationResult >> thisBuild) at >> ThoughtWorks.CruiseControl.Core.IntegrationRunner.GetModifications(IIntegrationResult >> from, IIntegrationResult to) at >> >> ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest >> request) >> >> 2009/7/3 Ruben Willems <[email protected]>: >> > Hi >> > >> > config looks ok to me, >> > >> > how are running ccnet? >> > as a service? >> > under which account? >> > >> > >> > can you post the error log? >> > >> > the relevant part that is >> > --> the stacktrace ;-) >> > >> > >> > with kind regards >> > Ruben Willems >> > >> > On Thu, Jul 2, 2009 at 7:08 PM, Adam Burton <[email protected]> >> > wrote: >> >> >> >> Hi, >> >> well, I don't know if it is Windows 2008 in specific but things were >> >> fine >> >> on >> >> Windows 2003 so I assume it is 2008. >> >> >> >> We use SVN for our source control and for some reason when a build is >> >> triggered automatically it first attempts a build which fails with an >> >> exception >> >> stating it cannot find svn.exe (checked the path, it is correct), >> >> minutes >> >> later >> >> another build is triggered (not scheduled, just the same build) which >> >> succeeds. I have tried setting ccservice.exe to run as Window XP SP2, >> >> no >> >> luck, >> >> also have it running as an administrator, also no luck. The weird thing >> >> is >> >> force builds from cctray work fine. >> >> >> >> Any ideas? >> >> >> >> Cheers, >> >> Adam >> > >> > > >
