Windows service fails to automatically start when using MsSQL.

[sgtwilko]

• Gitea version (or commit ref): 1.2.3
• Git version: N/A
• Operating system: Windows 2008R2 service.
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:
  2017/11/13 13:55:56 [...itea/routers/init.go:56 GlobalInit()] [E] Failed to initialize ORM engine: Login error: mssql: Neither the database "gitea" requested by the login nor the user default database could be opened. The master database is being used instead.

Description

When running as a windows service, even having added depend= MSSQLSERVER to the Gitea service so that it starts after MSSQL, Gitea is still failing to start due to the Gitea DB not yet being ready to use (see error above).

A possible fix may be to wait until the code below returns "ONLINE" prior to continuing starting up.

SELECT state_desc
FROM sys.databases
WHERE name = 'gitea'

[lunny]

It seems we can not do anything for this issue?

[andreynering]

There was another issue (I don't remember if for Gogs or Gitea) requesting for the app not to exit when cannot connect on database. (It would try to reconnect automatically if not connected).

[sgtwilko]

Does gitea know when it's running as a service?

If so, having it start up but the website respond that it can't connect to the db (whilst gitea could repeatedly attempt to connect) would be the best user experience.

If it doesn't know that it is a service, a config setting of waitForDB would work.

[lafriks]

You can set for windows service to repeat starting on failure

[MCF]

You can also set the Gitea service Startup Type to: Automatic (delayed start). It is a compromise solution as the default delayed start is 120 seconds after the last Automatic service has been started, so you end up with at least a 2 minute delay after the system is booted before Gitea is avaialable. Although you can add a registry key to change the 2 minute delay if you feel so inclined.

[pbrackin]

I was about to make a new issue then I found this. I think I have the code already written and tested that will solve this for you. Read on...

So, my issue was that I am running Gitea on Synology DiskStation using PostgreSQL in a Docker container. I was getting the same ORM errror. It was clear that Gitea was not being patient enough for this extra layer to become available. The Gitea package is already the last one to start & of course Docker starts well before Gitea. Normally, I would have solved this via a pre-start Upstart control, but Synology makes that a tall order by clamping down on the Package conf files. But really, it seemed like you needed a more robust connection logic; so, I just fixed the Gitea code.

I actually made a youtube about it here: https://www.youtube.com/watch?v=k_h_PSJSxF8

Only issue I think is.... I just wasn't sure if y'all wanted the constants into the config file or not. I will try to get the test suite runs done & make a pull request if there is not more feedback on this.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[techknowlogick]

Closing issue. Please open a post in the forum if this is still an issue.

[pbrackin]

PR is inbound...