Closed PaulBol closed 3 years ago
OK looks we need to add a trace level logger in. Can you adjust your logging to add a Trace level logger in as per https://docs.gitea.io/en-us/logging-configuration/#debugging-problems
i.e.
[log]
...
MODE=console, traceconsole
...
[log.traceconsole]
MODE = console
LEVEL = trace
EXPRESSION = modules/graceful
In particular I am looking for this to be logged:
I suspect that for whatever reason Gitea is not detecting that it is running as a windows service.
I had the same problem.
Gitea version (or commit ref): 1.14.0 Operating system: Windows Server 2019 v1809 Database: SQLite
Although the service starts with an error, the gitea process has been started and can also serve normally.
@sdweiyu whilst I appreciate you want to say that this is a problem, I need the logs I have asked for. I cannot fix this without them.
It would also be helpful to know how you registered gitea with the SVC and whether there are any logs available there.
Although the service starts with an error, the gitea process has been started and can also serve normally.
This part is different for my installation. When net start
returns the Gitea.exe process has terminated.
Anyway, I'll capture the trace level log and share it here like @zeripath suggested.
@zeripath - The log recorded with LEVEL = trace
and EXPRESSION = modules/graceful
does not show the line you pointed out:
2021/04/14 08:38:20 ...s/graceful/server.go:55:NewServer() [I] Starting new Web server: tcp:0.0.0.0:3000 on PID: 6248
2021/04/14 08:38:20 ...s/graceful/server.go:66:func1() [D] Starting server on tcp:0.0.0.0:3000 (PID: 6248)
2021/04/14 08:38:20 ...l/manager_windows.go:106:Execute() [T] Sending Running state to SVC
2021/04/14 08:38:20 ...l/manager_windows.go:114:Execute() [T] Started
I got one more without the EXPRESSION
filter. Do you see a problem here?
Ok well it looks that as far gitea is concerned it's connected to the SVC host...
Not logging that particular line is a good thing btw
@zeripath I got the log.
using:
[log]
MODE = file
LEVEL = trace
EXPRESSION = modules/graceful
ROOT_PATH = C:/gitea/log2
I use the command sc.exe create gitea .....
to create the service as the docs
gitea is updated from 1.14.0-rc2 to 1.14.0,
When starting the service from services.msc,there was an Error 1053: The service did not respond to the start or control request in a timely fashion.
When staring the servie from cmd net start gitea
, there was an error: The service is not responding to the control function.
Both of your logs indicate that gitea is connected to the SVC host and has sent the started state. So I'm not sure what's going on here.
Do you have logs when the SVC host claims that gitea hasn't started up?
It would also be useful to explicitly see an interrogate event, so after that startup message is sent with this trace logger running - is it possible to send an interrogate event? sc interrogate gitea
and see if the SVC sent interrogate trace log is emitted.
Maybe you need to set a STARTUP_TIMEOUT but the service is sending the startup status pretty rapidly.
Perhaps we need to be querying the interrogate whilst we are starting up and there's an out of date interrogate on the stack that has the wrong state? The go SVC docs for interrogate are weird and suggest that we should just send back the state the interrogate sent - I suspect that this is incorrect and we should be sending back out current state but this code hasn't changed so I don't understand why it should suddenly cause a problem.
I seem to have found a solution, I had previously used a dedicated user account _giteauser to run the service. app.config included RUN_USER = gitea_user
and the service had the log on account configured as .\gitea_user.
Looks like this configuration is not supported anymore. https://docs.gitea.io/en-us/windows-service/ now suggests to use COMPUTERNAME$. When I configured RUN_USER = COMPUTERNAME$
and let the service use Local System, Gitea is working normally.
@sdweiyu - I observed the same behavior that you reported when I had the service configured to run as Local System but still had set RUN_USER = gitea_user
. What I mean is that net start
would respond with The service is not responding to the control function.
and the Gitea.exe process kept running.
@zeripath - Just read your posts, thanks for the input. Is it still worth trying sc interrogate gitea
and playing around with STARTUP_TIMEOUT
or should I just accept that the old user setup is not supported anymore and should be updated as described above?
Ok so I don't understand why the run_user thing is needed - the person that changed that documentation didn't change the code so it's perhaps related to how they've suggested the service be started?
If however changing the run user works and that's what the docs suggest then ... I guess we can close.
Feel free to check out the interrogate thing tho and try to work out why the old user thing isn't working
sc interrogate gitea
consistently responded with [SC] ControlService FAILED 1062: The service has not been started.
while net start gitea
was running and afterwards.
Maybe interacting with the service manager has changed in a way that now requires additional privileges? I guess running the service with an admin account instead of a regular user account could tell. However, if this setup isn't recommended and not mentioned in the documentation I don't see much sense in trying to get it to work.
Feel free to close the issue unless @sdweiyu has additional insights or concerns. Thanks again for the quick and helpful response! 👏
I configured RUN_USER = COMPUTERNAME$(name of my server),but the same error is still there.
Because there is no problem with v1.14.0-rc2, the error on v1.14.0 may be just an accident on my server :(
Maybe the next version will be ok.
thanks @PaulBol @zeripath
We observed exactly the same behaviour on our test-system wehn trying to update to Gitea 1.14.0. Using the Local System account to run Gitea is no solution for us as it breaks functionality we need. The Local System account has no accesss to network ressources (network file shares in our company) and in our scenario is not allowed to connect to the internet. So in our case, switching to the Local System account breaks Github mirroring and repository migrations from network shares. We need to be able to run the Gitea service with a domain account. I will try to increase the service timeout this evening and see if this helps.
I increased the windows service timeout to 180000 milliseconds. Unfortunately, that didn't help. I also tested with the newly realeased Gitea version 1.4.1. But the same error still occurs.
Could it be a problem with the svc?
Because these lines should send the state? https://github.com/go-gitea/gitea/blob/9c4601bdf8369ed72944085e3952111cf4aeea11/modules/graceful/manager_windows.go#L106-L114
2021/04/16 10:07:33 ...l/manager_windows.go:106:Execute() [T] Sending Running state to SVC
2021/04/16 10:07:33 ...l/manager_windows.go:114:Execute() [T] Started
Is there an
updateStatus
missing? Because status is only a structure?
I am not familiar with the go syntax. But if the status update wouldn't execute why can the service run as Local System and only not as a regular user?
@skgeo - For me running as Local System is acceptable therefore I didn't dig deeper (after I got gpg configured correctly which was the hardest part...).
The next thing I would have tried is running the service with a local or domain admin account. If that works you could try if it still runs with a somewhat more restricted account, e.g. from the Backup Operators or Power Users group.
Is there an
updateStatus
missing? Because status is only a structure?I am not familiar with the go syntax. But if the status update wouldn't execute why can the service run as Local System and only not as a regular user?
I removed this line from my comment, because it seems to be go channel magic. I am not an go developer. The return value of SetServiceState should give a hint.
I investigated further and tried the following:
Adding the domain account used to run the gitea windows service to the Administrators
group of the server.
-> This works. The gitea service starts without problem. But this is of course not a solution. We can't run gitea with administrative privileges.
Adding the domain account used to run the gitea windows service to the Backup Operators
group of the server.
-> unfortunately this doesn't help.
Adding the domain account used to run the gitea windows service to the Power Users
group of the server.
-> unfortunately this doesn't help.
giving the domain account used to run the gitea windows service full permissions on the gitea servcie using the security descriptor (A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-xxxxxxxxxxxx)
-> unfortunately this doesn't help.
So the change hasn't really come from anything within Gitea - but within the upstream x/sys/windows/svc
library
I wonder if the issue is the | acceptHammerCode,
and if Windows' SVC host now requires additional permissions for this.
You could try removing this to see if it fixes the problem?
@skgeo are you able to build or do you need me to provide a build with this removed?
@zeripath It would be great if you could provide me a build. I have never done this myself. But I am very willing to test.
agh! sorry I missed your message: https://eldritchkitty.com/~andrew/gitea-1.14.x-4fa280423-no-hammer-windows-4.0-amd64.exe
@zeripath I have the same issue. Gitea 1.14.1 cannot start as service (timeout error 1053) but runs fine when running from command line. My config was OK with my previous version 1.13.0.
I've just tried your modified version above (no-hammer) but got the same error. Sending you the tracelogs of that and also the original 1.14.1: gitea1.14.1-logs.zip
My config uses a dedicated user to run Gitea.
All is fine when running from command line like this:
runas /user:git "cmd /k C:\RS7\gitea\gitea.exe web --config E:\RS7\gitea\custom\conf\app.ini"
My service command (created with sc based on the docs):
"C:\RS7\gitea\gitea.exe" web --config "E:\RS7\gitea\custom\conf\app.ini"
I've increased the ServicesPipeTimeout
and WaitToKillServiceTimeout
Windows registry keys to 60sec, but didn't help. When I try to start the service manually, after a few seconds I can access Gitea on https as it should but the loading indicator of the service still shows that it's loading... After the 60sec timeout the process gets terminated. So I can confirm, that Gitea starts up, but Windows doesn't recognizes that it started successfully.
My system is: Windows 10 Pro 64bit version 20H2 build 19042.928
Thank you for your efforts!
Until this gets fixed, I'm sharing my temporary workaround to make it work as a service again. Use it at your own risk, I can't guarantee that it has no drawbacks or any unexpected behavior...
The workaround is based on the open-source project called WinSW.
WinSW wraps and manages any application as a Windows service.
(BTW I'm also using WinSW for a long time running my local Nginx server - which serves Gitea - on Windows without any problem.)
So I followed their "Use WinSW as a bundled tool" instructions and made my gitea-winsw.exe
- which is WinSW.NET461.exe
renamed (requires .NET installed!) - and gitea-winsw.xml
in my Gitea dir.
In my case, the xml file looks like this (modify it for your needs):
<configuration>
<id>gitea-winsw</id>
<name>gitea-winsw</name>
<description>Gitea-WinSW</description>
<executable>%BASE%\gitea.exe</executable>
<arguments>web --config E:\RS7\gitea\custom\conf\app.ini</arguments>
<workingdirectory>E:\RS7\gitea</workingdirectory>
<logpath>E:\RS7\gitea\log</logpath>
<logmode>roll</logmode>
<depend></depend>
</configuration>
Although this service can be installed with the --user
and --pass
options, I omitted them and rather set the login info later by modifying the created service using services.msc
and the Log On
tab (as usual). So my install command was only:
.\gitea-winsw.exe install
This successfully created my new gitea-winsw
service. Now I've just set my desired user to run this service and started it.
Gitea is running fine again!
So I think this has to be an issue with Windows permissions or with x/net/sys/windows. The underlying Gitea code has not changed.
Is it possible that you need to explicitly give the full path to gitea?
https://github.com/golang/go/issues/42596#issuecomment-730250900
And that API requires you to provide full path to your service executable (see lpBinaryPathName parameter). And, once installed, the service executable cannot be moved (until service is deleted), because Windows will try to run it when you request Windows to start your service.
Could one of you try the example code from x/sys/windows/svc to see if that works for you?
@zeripath Sure, I would, but I have no experience with golang.
I have go
installed via Scoop
on my Windows (go version go1.16.3 windows/amd64)
I've just run go get -u golang.org/x/sys
so I have it here:
c:\Users\johndoe\go\pkg\mod\golang.org\x\sys@v0.0.0-20210503173754-0981d6026fa6\windows\svc\example\
but I have no clue how to continue (build/install/whatever).
If it's not rocket science and you give me some info I would try the example service happily.
@coderars from inside the c:\Users\johndoe\go\pkg\mod\golang.org\x\sys@v0.0.0-20210503173754-0981d6026fa6\windows\svc\example\
run go build
should create an example.exe
I've pushed a crosscompile up at https://edlritchkitty.com/~andrew/example.exe
@zeripath thank you, the command go build
really did the job... 😄
However, after installing the example service - my service
- the result is the same (error 1053) as soon as I change its Log On
settings from Local System account
to another local user account. The error message pops up right after starting the service.
I've tried it with my git user and another one but it doesn't matter. Also checked that those users have the Log on as service
permission in Local Security Policy
. So I'm almost certain that my Windows settings are OK.
Running it from command line .\example.exe start
raises the same error message:
failed to start myservice: could not start service: The service did not respond to the start or control request in a timely fashion.
...and:
Is it possible that you need to explicitly give the full path to gitea?
I've tried that with both Gitea and this example with the same result.
When I set the user to myself (the user currently logged in with admin rights) it works because it's an admin account, but it was discussed above that with admin rights it works.
Tested on my Windows 10 Pro version 20H2 build 19042.964
Ok so, I think that proves that this is not a gitea bug per se but an upstream issue.
Could you open an issue on https://github.com/golang/go/issues. Prefix your issue with "x/sys:" in the subject line, and mention your issues with the example.exe and reference this issue.
@zeripath OK, done. Looking at the commits history of x/sys
and after some test builds from earlier versions I assume that our issue is because of this commit on Oct 8, 2020. Building the svc example from a version (Oct 7, 2020) right before that commit does not raise this issue. Hope it helps...
OK I'm gonna upload one using the IsAnInteractiveSession as a final attempt.
https://eldritchkitty.com/~andrew/gitea-1.14.x-f9b1fac4ea-isaninteractive-windows-4.0-amd64.exe
@zeripath seems OK!! Start/Restart, all works as expected.
OK so this is very likely a permissions issue to do with the IsAWindowsService so could you open an issue above and I'll put a PR up that just drops us to use the deprecated function. I'd make the upstream issue myself but I'm not a windows user and so can't really apply any of their fixes or try to fix things. (Just add an @zeripath to the message so I can keep a watch about what the actual fix is in the end.)
@zeripath is it what you mean? Should I modify something?
agh! sorry, I didn't see that you've already opened https://github.com/golang/go/issues/45966 in golang. I just meant to include your information there.
I'll close #15750 as it's just a duplicate of this one.
That's why I was confused... 😃 No worries. Maybe you could add some technical thoughts there with the info you gathered. This all is now far above my knowledge (actually I've never written a line in go...)
One last: Maybe the issue 44921 @ golang/go is related to this and could be interesting to you (don't want to link it in case if not).
Thank you for all your efforts on this!
It's possible that's related but the interesting thing is that at least for one person above it appears it was detecting a Windows service correctly. I'm not sure though - perhaps I missed the trace message saying that it wasn't running as a service.
Log
2021/04/13 18:23:56 ...dules/setting/log.go:333:newLogService() [I] Gitea Log Mode: File(File:debug) 2021/04/13 18:23:56 ...dules/setting/log.go:250:generateNamedLogger() [I] Router Log: Console(console:debug) 2021/04/13 18:23:56 ...les/setting/cache.go:73:newCacheService() [I] Cache Service Enabled 2021/04/13 18:23:56 ...les/setting/cache.go:88:newCacheService() [I] Last Commit Cache Service Enabled 2021/04/13 18:23:56 ...s/setting/session.go:77:newSessionService() [I] Session Service Enabled 2021/04/13 18:23:56 ...es/setting/mailer.go:109:newMailService() [I] Mail Service Enabled 2021/04/13 18:23:56 ...es/setting/mailer.go:120:newRegisterMailService() [I] Register Mail Service Enabled 2021/04/13 18:23:56 ...es/setting/mailer.go:131:newNotifyMailService() [I] Notify Mail Service Enabled 2021/04/13 18:23:56 ...s/storage/storage.go:158:initAttachments() [I] Initialising Attachment storage with type: 2021/04/13 18:23:56 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at C:\Gitea\data\attachments 2021/04/13 18:23:56 ...s/storage/storage.go:152:initAvatars() [I] Initialising Avatar storage with type: 2021/04/13 18:23:56 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at C:\Gitea\data\avatars 2021/04/13 18:23:56 ...s/storage/storage.go:170:initRepoAvatars() [I] Initialising Repository Avatar storage with type: 2021/04/13 18:23:56 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at C:\Gitea\data\repo-avatars 2021/04/13 18:23:56 ...s/storage/storage.go:164:initLFS() [I] Initialising LFS storage with type: 2021/04/13 18:23:56 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at C:/Gitea/data/lfs 2021/04/13 18:23:56 ...ueue_disk_channel.go:137:Run() [D] PersistableChannelQueue: push_update Starting 2021/04/13 18:23:56 ...ue/queue_bytefifo.go:96:Run() [D] level: push_update-level Starting 2021/04/13 18:23:56 ...ueue_disk_channel.go:137:Run() [D] PersistableChannelQueue: mail Starting 2021/04/13 18:23:56 ...ue/queue_bytefifo.go:96:Run() [D] level: mail-level Starting 2021/04/13 18:23:56 ...ueue_disk_channel.go:137:Run() [D] PersistableChannelQueue: notification-service Starting 2021/04/13 18:23:56 ...ue/queue_bytefifo.go:96:Run() [D] level: notification-service-level Starting 2021/04/13 18:23:56 routers/init.go:150:GlobalInit() [I] SQLite3 Supported 2021/04/13 18:23:56 routers/init.go:68:initDBEngine() [I] Beginning ORM engine initialization. 2021/04/13 18:23:56 routers/init.go:75:initDBEngine() [I] ORM engine initialization attempt #1/10... 2021/04/13 18:23:56 ...om/urfave/cli/app.go:524:HandleAction() [I] PING DATABASE mssql 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table user Column keep_email_private db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table user Column last_repo_visibility db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table user Column is_active db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table user Column is_admin db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table user Column allow_git_hook db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table user Column allow_import_local db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table user Column allow_create_organization db default is 0, struct default is 1 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table user Column use_custom_avatar db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table user column theme db type is NVARCHAR(30), struct type is NVARCHAR(255) 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table user Column keep_activity_private db default is , struct default is 0 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table user Column keep_activity_private db nullable is true, struct nullable is false 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table repository column description db type is NVARCHAR(255), struct type is NVARCHAR(MAX) 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table repository column website db type is NVARCHAR(255), struct type is NVARCHAR(2048) 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table repository Column original_service_type db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table repository column original_url db type is NVARCHAR(255), struct type is NVARCHAR(2048) 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table repository Column is_private db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table repository Column is_mirror db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table repository Column is_fsck_enabled db default is 0, struct default is 1 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table upload column uuid db type is NVARCHAR(40), struct type is VARCHAR(40) 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table issue Column is_closed db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table issue Column is_pull db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table pull_request Column has_merged db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table comment Column removed_assignee db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table comment Column invalidated db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table comment has column old_assignee_id but struct has not related field 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table attachment column uuid db type is NVARCHAR(40), struct type is VARCHAR(40) 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table milestone Column is_closed db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table mirror Column enable_prune db default is 0, struct default is 1 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table webhook Column is_system_webhook db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table webhook Column is_system_webhook db nullable is false, struct nullable is true 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table webhook Column http_method db default is 'POST', struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table webhook Column is_ssl db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table webhook Column is_active db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table hook_task Column is_ssl db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table hook_task Column is_delivered db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table hook_task Column is_succeed db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table org_user Column is_public db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table email_address Column is_activated db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table issue_user Column is_read db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table issue_user Column is_mentioned db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table gpg_key Column can_sign db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table gpg_key Column can_encrypt_comms db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table gpg_key Column can_encrypt_storage db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table gpg_key Column can_certify db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table external_login_user column access_token db type is NVARCHAR(255), struct type is NVARCHAR(MAX) 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table external_login_user column access_token_secret db type is NVARCHAR(255), struct type is NVARCHAR(MAX) 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table external_login_user column refresh_token db type is NVARCHAR(255), struct type is NVARCHAR(MAX) 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table protected_branch Column enable_whitelist db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table issue_watch Column is_watching db default is 0, struct default is 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table tracked_time Column time db nullable is true, struct nullable is false 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table review column type db type is NVARCHAR(255), struct type is INT 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table language_stat Column language db nullable is true, struct nullable is false 2021/04/13 18:23:56 ...rfave/cli/command.go:173:Run() [W] Table session has column created_unix but struct has not related field 2021/04/13 18:23:56 routers/init.go:155:GlobalInit() [I] ORM engine initialization successful! 2021/04/13 18:23:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: update_mirrors 2021/04/13 18:23:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: repo_health_check 2021/04/13 18:23:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: check_repo_stats 2021/04/13 18:23:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: archive_cleanup 2021/04/13 18:23:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: sync_external_users 2021/04/13 18:23:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: deleted_branches_cleanup 2021/04/13 18:23:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: update_migration_poster_id 2021/04/13 18:23:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: cleanup_hook_task_table 2021/04/13 18:23:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: delete_inactive_accounts 2021/04/13 18:23:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: delete_repo_archives 2021/04/13 18:23:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: git_gc_repos 2021/04/13 18:23:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: resync_all_sshkeys 2021/04/13 18:23:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: resync_all_sshprincipals 2021/04/13 18:23:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: resync_all_hooks 2021/04/13 18:23:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: reinit_missing_repos 2021/04/13 18:23:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: delete_missing_repos 2021/04/13 18:23:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: delete_generated_repository_avatars 2021/04/13 18:23:57 ...er/issues/indexer.go:142:func2() [I] PID 5476: Initializing Issue Indexer: bleve 2021/04/13 18:23:57 ...er/issues/indexer.go:171:func2() [D] Created Bleve Indexer 2021/04/13 18:23:57 ...er/issues/indexer.go:221:func3() [I] Issue Indexer Initialization took 8.0033ms 2021/04/13 18:23:57 ...ue/queue_bytefifo.go:96:Run() [D] level: issue_indexer Starting 2021/04/13 18:23:57 ...ueue_disk_channel.go:162:Run() [D] PersistableChannelUniqueQueue: repo_stats_update Starting 2021/04/13 18:23:57 ...ue/queue_bytefifo.go:96:Run() [D] unique-level: repo_stats_update-level Starting 2021/04/13 18:23:57 ...xer/stats/indexer.go:38:populateRepoIndexer() [I] Populating the repo stats indexer with existing repositories 2021/04/13 18:23:57 ...xer/stats/indexer.go:84:populateRepoIndexer() [I] Done (re)populating the repo stats indexer with existing repositories 2021/04/13 18:23:57 ...ueue_disk_channel.go:162:Run() [D] PersistableChannelUniqueQueue: pr_patch_checker Starting 2021/04/13 18:23:57 ...ue/queue_bytefifo.go:96:Run() [D] unique-level: pr_patch_checker-level Starting 2021/04/13 18:23:57 ...ueue_disk_channel.go:137:Run() [D] PersistableChannelQueue: task Starting 2021/04/13 18:23:57 ...ue/queue_bytefifo.go:96:Run() [D] level: task-level Starting 2021/04/13 18:23:57 ...i/websspi_windows.go:87:New() [I] Credential handle expiry: 2185-07-21 00:34:33.712009116 +0100 CET 2021/04/13 18:23:59 cmd/web.go:189:listen() [I] Listen: https://0.0.0.0:3000 2021/04/13 18:23:59 cmd/web.go:192:listen() [I] LFS server enabled 2021/04/13 18:23:59 ...s/graceful/server.go:55:NewServer() [I] Starting new Web server: tcp:0.0.0.0:3000 on PID: 5476 2021/04/13 18:23:59 ...s/graceful/server.go:66:func1() [D] Starting server on tcp:0.0.0.0:3000 (PID: 5476)Description
I'm running Gitea as a Windows service. Service GiteaSvc is launching
C:\Gitea\gitea.exe web --config C:\Gitea\conf\app.ini
. This was working fine until updating from version 1.13.4 to 1.14.0. Now attempting to runnet start giteasvc
results inThe Windows event logs show errors 7009 and 7000:
A timeout was reached (30000 milliseconds) while waiting for the GiteaSvc service to connect.
The GiteaSvc service failed to start due to the following error: The service did not respond to the start or control request in a timely fashion.
I captured debug logs but didn't notice anything that looks like an error. Running
C:\Gitea\gitea.exe web --config C:\Gitea\conf\app.ini
from a command line window still works fine.Can anyone please help me to restore my Gitea installation? Happy to try out things or supply additional information.