Windows service fails to automatically start when using MsSQL. #1241

New Issue

GiteaMirror · 2025-11-02T03:53:36-06:00

GiteaMirror commented

2025-11-02 03:53:36 -06:00

Originally created by @sgtwilko on GitHub (Nov 13, 2017).

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'

Originally created by @sgtwilko on GitHub (Nov 13, 2017). - Gitea version (or commit ref): 1.2.3 - Git version: N/A - Operating system: Windows 2008R2 service. - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [x] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] 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. ```sql SELECT state_desc FROM sys.databases WHERE name = 'gitea' ```

GiteaMirror added the type/enhancement issue/stale labels 2025-11-02 03:53:36 -06:00

GiteaMirror closed this issue

2025-11-02 03:53:36 -06:00

GiteaMirror commented

2025-11-02 03:53:37 -06:00

@lunny commented on GitHub (Nov 13, 2017):

It seems we can not do anything for this issue?

@lunny commented on GitHub (Nov 13, 2017): It seems we can not do anything for this issue?

GiteaMirror commented

2025-11-02 03:53:37 -06:00

@andreynering commented on GitHub (Nov 14, 2017):

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).

@andreynering commented on GitHub (Nov 14, 2017): 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).

GiteaMirror commented

2025-11-02 03:53:37 -06:00

@sgtwilko commented on GitHub (Nov 14, 2017):

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.

@sgtwilko commented on GitHub (Nov 14, 2017): 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.

GiteaMirror commented

2025-11-02 03:53:37 -06:00

@lafriks commented on GitHub (Nov 14, 2017):

You can set for windows service to repeat starting on failure

@lafriks commented on GitHub (Nov 14, 2017): You can set for windows service to repeat starting on failure

GiteaMirror commented

2025-11-02 03:53:38 -06:00

@MCF commented on GitHub (Dec 19, 2017):

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.

@MCF commented on GitHub (Dec 19, 2017): 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](https://social.technet.microsoft.com/Forums/windows/en-US/d8f0e315-74d4-4890-a62f-ef427a8532e1/adjusting-the-autostart-delayed-start-time?forum=winservergen) to change the 2 minute delay if you feel so inclined.

GiteaMirror commented

2025-11-02 03:53:38 -06:00

@pbrackin commented on GitHub (Sep 25, 2018):

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.

@pbrackin commented on GitHub (Sep 25, 2018): 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.

GiteaMirror commented

2025-11-02 03:53:38 -06:00

@stale[bot] commented on GitHub (Jan 8, 2019):

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.

@stale[bot] commented on GitHub (Jan 8, 2019): 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.

GiteaMirror commented

2025-11-02 03:53:38 -06:00

@techknowlogick commented on GitHub (Jan 14, 2019):

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

@techknowlogick commented on GitHub (Jan 14, 2019): Closing issue. Please open a post in the [forum](https://discourse.gitea.io/) if this is still an issue.

GiteaMirror commented

2025-11-02 03:53:39 -06:00

@pbrackin commented on GitHub (Jan 15, 2019):

PR is inbound...

@pbrackin commented on GitHub (Jan 15, 2019): PR is inbound...

GiteaMirror referenced this issue

2025-11-02 11:55:32 -06:00

[PR #1241] [MERGED] Fix migration comment #15827

Sign in to join this conversation.