We have been using Octopus(3.15.7) in our build server.It works smoothly except the times when for some reason when we reboot the build server(like when I applying any patch), the octopus service takes around half an hour to start. It shows as Starting in services list(services.msc) , but when we see the logs it shows that
Login failed for user “OctopusUser”.
Then after repeated attempts by this service as seen in the logs, Octopus database is able to connect for that user, all that takes atleast half an hour, till then our deployments get impacted.
In which logs is that appearing? Is it related to the service logon or to the SQL connection?
What account is the octopus service running under?
Are there any other services in the starting state? For example the
MSSSQLServer service or something related with Active Directory authentication? Is Octopus using any network drives that may not be immediately available?
Could you send me the server logs for the time period covered by this start.
Do you have the Watchdog setup?
If you are seeing this in the Event Log, could you send me the full details? Does the Eventlog indicate that the service is continually stopping and starting, or is it just the single service start?
This error is from the Octopus logs configured to be at following location D:\Octopus\Home\Logs\Octopusserver.log
This happened on July 15th , unfortunately the old logs get cleared automatically, I can’t find even in the files Octopusserver.[n].txt
Let me explain the sequence
We reboot the build server for some reason where Octopus was hosted
After that Octopus url was not working, we checked the services list using command services.msc and found that Octopus Deploy service was in stopped state
I restarted that service and the status starting showing Starting
I browsed to logs located at D:\Octopus\Home\Logs\Octopusserver.txt and found that there was repetitive error
Login failed for user “OctopusUser”.
a. During this time, we tried login to sql server manually through same credentials via SQL server management studio and we were able to login.
b. Also we checked the SQL Server (MSSQLSERVER) and SQL Server Agent (MSSQLSERVER) services those were in Started state.
We waited for this to Start, and it took half an hour for that but eventually came up
Octopus Deploy service is set up as Start automatically and runs on service account.
Octopus Deploy service uses SQL server as database and uses sql authentication to connect.
Octopus is kkw
I think the end of your message got cut off.
We haven’t seen this kind of error before, so without the logs, I’m stumped as to where to start looking. The next time it happens, could you capture those logs and send them to us? Also does it only happen on server restart, or when the service restarts?
Could you check the SQL server logs to see if it logged failed login attempts?
Finally, if you can capture a process dump at the time of the problem occurring, I can analyse that to see exactly where in the code it is.
The cut-off message was
Octopus is not dependent upon any network drives
I don’t think we have watchdog setup
Now(recently added by me)
Actually I recalled what happened( start vs restart service)
Server rebooted, service was in stopped state.
I started service, it failed to start and throws error in less than a minute.
I restarted service, this time it takes time to start and till then shows starting in list of services. This is when multiple attempts to connect to SQL server has been logged.
Dump file is too large (in gigs )
I’ve created a secure upload site for a dump file https://file.ac/DWJCBJTkzXo/, it should also zip quite a bit.
The dump file is only useful if it is captured while the process is experiencing this issue.
Hi Robert- It will take 2 hrs to upload, so I cancelled it
Is there any way to open this file in any editor and send you the information for the day when the problem occurred
The dump file? It would only contain the data at the time the problem was
occurring. Have you encountered the problem again and taken a dump? A dump
when the problem is not occurring would not help.
I haven’t encountered the problem again,how can we proceed further
The next time it occurs, could you capture the process dump along with the server and event logs. Also check the SQL Server logs for why the login failed (password, permissions, etc).