github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 10:39:38 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Gitea web server receives SIGTERM and shuts down a few minutes or a few seconds after starting #10995

New Issue
Closed
opened 2025-11-02 09:24:19 -06:00 by GiteaMirror · 5 comments
GiteaMirror commented 2025-11-02 09:24:19 -06:00
Owner
Copy Link

Originally created by @jducaud on GitHub (Jun 8, 2023).

Description

  1. I start the Gitea Docker container: sudo docker-compose up -d
  2. The Gitea web server comes up
  3. A few minutes (or sometimes seconds) later, the Gitea web server shuts down

It seems that the Gitea web server receives a SIGTERM.
Here is a log excerpt (nothing has been stripped between those 2 lines) where the Gitea web server is alive during 48 seconds:

2023/06/08 21:39:21 ...s/graceful/server.go:62:NewServer() [I] Starting new Web server: tcp:0.0.0.0:3000 on PID: 17
2023/06/08 21:40:09 ...eful/manager_unix.go:198:handleSignals() [W] PID 17. Received SIGTERM. Shutting down...

Sometimes I feel like I can make it last longer (a few minutes) just by logging in and interacting with the web UI. But I may be wrong about this feeling.
I have never experimented such an issue with Gitea. This is the first time. The Docker image 1.19 (which was - according to Docker - 5-week old) worked perfectly. This "latest" Docker image 1.20.0+rc0 is not viable, at least on my Synology NAS, and I do not know why (Watchtower updated Gitea image last night while I was sleeping, and suddenly, the Gitea web server was gone).

REPOSITORY              TAG            IMAGE ID       CREATED        SIZE
gitea/gitea             latest         a300af46a97b   19 hours ago   270MB
gitea/gitea             1.20-nightly   492029a1dca3   19 hours ago   270MB
gitea/gitea             1.19           a330505109c5   5 weeks ago    268MB

Of course I tried to go back to the version 1.19. But it seems that it is no longer possible due to an irreversible database migration from 1.19 to 1.20. I also tried (without any hope) the 1.20-nightly image (which is probably nearly identical to the latest image) and had no success.
Here is the complete log:

2023/06/08 21:39:20 ...les/setting/cache.go:75:loadCacheFrom() [I] Cache Service Enabled
2023/06/08 21:39:20 ...les/setting/cache.go:90:loadCacheFrom() [I] Last Commit Cache Service Enabled
2023/06/08 21:39:20 ...s/setting/session.go:74:loadSessionFrom() [I] Session Service Enabled
2023/06/08 21:39:20 ...es/setting/mailer.go:237:loadMailerFrom() [I] Mail Service Enabled
2023/06/08 21:39:20 ...es/setting/mailer.go:248:loadRegisterMailFrom() [I] Register Mail Service Enabled
2023/06/08 21:39:20 ...es/setting/mailer.go:259:loadNotifyMailFrom() [I] Notify Mail Service Enabled
2023/06/08 21:39:20 ...s/storage/storage.go:177:initAttachments() [I] Initialising Attachment storage with type: 
2023/06/08 21:39:20 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/attachments
2023/06/08 21:39:20 ...s/storage/storage.go:167:initAvatars() [I] Initialising Avatar storage with type: 
2023/06/08 21:39:20 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/avatars
2023/06/08 21:39:20 ...s/storage/storage.go:193:initRepoAvatars() [I] Initialising Repository Avatar storage with type: 
2023/06/08 21:39:20 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/repo-avatars
2023/06/08 21:39:20 ...s/storage/storage.go:187:initLFS() [I] Initialising LFS storage with type: 
2023/06/08 21:39:20 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/git/lfs
2023/06/08 21:39:20 ...s/storage/storage.go:199:initRepoArchives() [I] Initialising Repository Archive storage with type: 
2023/06/08 21:39:20 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/repo-archive
2023/06/08 21:39:20 ...s/storage/storage.go:209:initPackages() [I] Initialising Packages storage with type: 
2023/06/08 21:39:20 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/packages
2023/06/08 21:39:20 routers/init.go:136:GlobalInitInstalled() [I] SQLite3 support is enabled
2023/06/08 21:39:20 routers/common/db.go:21:InitDBEngine() [I] Beginning ORM engine initialization.
2023/06/08 21:39:20 routers/common/db.go:28:InitDBEngine() [I] ORM engine initialization attempt #1/10...
2023/06/08 21:39:20 cmd/web.go:177:runWeb() [I] PING DATABASE sqlite3
2023/06/08 21:39:20 routers/init.go:141:GlobalInitInstalled() [W] Table system_setting Column version db default is , struct default is 1
2023/06/08 21:39:20 routers/init.go:141:GlobalInitInstalled() [W] Table project Column card_type db default is 0, struct default is 
2023/06/08 21:39:20 routers/init.go:141:GlobalInitInstalled() [W] Table project Column card_type db nullable is false, struct nullable is true
2023/06/08 21:39:20 routers/init.go:141:GlobalInitInstalled() [W] Table hook_task has column repo_id but struct has not related field
2023/06/08 21:39:20 routers/init.go:142:GlobalInitInstalled() [I] ORM engine initialization successful!
2023/06/08 21:39:20 ...er/issues/indexer.go:156:func2() [I] PID 17: Initializing Issue Indexer: bleve
2023/06/08 21:39:20 ...er/issues/indexer.go:246:func3() [I] Issue Indexer Initialization took 1.147598ms
2023/06/08 21:39:20 ...xer/stats/indexer.go:38:populateRepoIndexer() [I] Populating the repo stats indexer with existing repositories
2023/06/08 21:39:20 ...xer/stats/indexer.go:84:populateRepoIndexer() [I] Done (re)populating the repo stats indexer with existing repositories
2023/06/08 21:39:21 cmd/web.go:235:listen() [I] Listen: http://0.0.0.0:3000
2023/06/08 21:39:21 cmd/web.go:239:listen() [I] AppURL(ROOT_URL): https://my.domain-name.fr/
2023/06/08 21:39:21 cmd/web.go:242:listen() [I] LFS server enabled
2023/06/08 21:39:21 ...s/graceful/server.go:62:NewServer() [I] Starting new Web server: tcp:0.0.0.0:3000 on PID: 17
2023/06/08 21:40:09 ...eful/manager_unix.go:198:handleSignals() [W] PID 17. Received SIGTERM. Shutting down...
2023/06/08 21:40:09 cmd/web.go:286:listen() [I] HTTP Listener: 0.0.0.0:3000 Closed
2023/06/08 21:40:09 ...eful/server_hooks.go:46:doShutdown() [I] PID: 17 Listener ([::]:3000) closed.
2023/06/08 21:40:09 .../graceful/manager.go:168:doHammerTime() [W] Setting Hammer condition
2023/06/08 21:40:10 .../graceful/manager.go:184:doTerminate() [W] Terminating
2023/06/08 21:40:10 ...er/issues/indexer.go:183:2() [I] PID: 17 Issue Indexer closed
2023/06/08 21:40:10 ...eful/manager_unix.go:208:handleSignals() [W] PID: 17. Background context for manager closed - context canceled - Shutting down...
2023/06/08 21:40:10 cmd/web.go:197:runWeb() [I] PID: 17 Gitea Web Finished

Gitea Version

1.20.0+rc0 built with GNU Make 4.4.1, go1.20.5 : bindata, timetzdata, sqlite, sqlite_unlock_notify

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.40.1, Wire Protocol Version 2 Enabled

Operating System

Synology DSM 6.2.4 build 25556 update 7 - Docker

How are you running Gitea?

Docker image: gitea/gitea:latest
But as it is said in #25136 (which is a respawn of #21615) instead of getting a stable Docker release, last night Watchtower updated the Gitea image to a release candidate one (thus from 1.19 to 1.20.0+rc0)

Database

SQLite

Originally created by @jducaud on GitHub (Jun 8, 2023). ### Description 1. I start the Gitea Docker container: `sudo docker-compose up -d` 2. The Gitea web server comes up 3. A few minutes (or sometimes seconds) later, the Gitea web server shuts down It seems that the Gitea web server receives a SIGTERM. Here is a log excerpt (nothing has been stripped between those 2 lines) where the Gitea web server is alive during 48 seconds: ``` 2023/06/08 21:39:21 ...s/graceful/server.go:62:NewServer() [I] Starting new Web server: tcp:0.0.0.0:3000 on PID: 17 2023/06/08 21:40:09 ...eful/manager_unix.go:198:handleSignals() [W] PID 17. Received SIGTERM. Shutting down... ``` Sometimes I feel like I can make it last longer (a few minutes) just by logging in and interacting with the web UI. But I may be wrong about this feeling. I have never experimented such an issue with Gitea. This is the first time. The Docker image `1.19` (which was - according to Docker - 5-week old) worked perfectly. This "latest" Docker image `1.20.0+rc0` is not viable, at least on my Synology NAS, and I do not know why (Watchtower updated Gitea image last night while I was sleeping, and suddenly, the Gitea web server was gone). ``` REPOSITORY TAG IMAGE ID CREATED SIZE gitea/gitea latest a300af46a97b 19 hours ago 270MB gitea/gitea 1.20-nightly 492029a1dca3 19 hours ago 270MB gitea/gitea 1.19 a330505109c5 5 weeks ago 268MB ``` Of course I tried to go back to the version `1.19`. But it seems that it is no longer possible due to an irreversible database migration from `1.19` to `1.20`. I also tried (without any hope) the `1.20-nightly` image (which is probably nearly identical to the `latest` image) and had no success. Here is the complete log: ``` 2023/06/08 21:39:20 ...les/setting/cache.go:75:loadCacheFrom() [I] Cache Service Enabled 2023/06/08 21:39:20 ...les/setting/cache.go:90:loadCacheFrom() [I] Last Commit Cache Service Enabled 2023/06/08 21:39:20 ...s/setting/session.go:74:loadSessionFrom() [I] Session Service Enabled 2023/06/08 21:39:20 ...es/setting/mailer.go:237:loadMailerFrom() [I] Mail Service Enabled 2023/06/08 21:39:20 ...es/setting/mailer.go:248:loadRegisterMailFrom() [I] Register Mail Service Enabled 2023/06/08 21:39:20 ...es/setting/mailer.go:259:loadNotifyMailFrom() [I] Notify Mail Service Enabled 2023/06/08 21:39:20 ...s/storage/storage.go:177:initAttachments() [I] Initialising Attachment storage with type: 2023/06/08 21:39:20 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/attachments 2023/06/08 21:39:20 ...s/storage/storage.go:167:initAvatars() [I] Initialising Avatar storage with type: 2023/06/08 21:39:20 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/avatars 2023/06/08 21:39:20 ...s/storage/storage.go:193:initRepoAvatars() [I] Initialising Repository Avatar storage with type: 2023/06/08 21:39:20 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/repo-avatars 2023/06/08 21:39:20 ...s/storage/storage.go:187:initLFS() [I] Initialising LFS storage with type: 2023/06/08 21:39:20 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/git/lfs 2023/06/08 21:39:20 ...s/storage/storage.go:199:initRepoArchives() [I] Initialising Repository Archive storage with type: 2023/06/08 21:39:20 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/repo-archive 2023/06/08 21:39:20 ...s/storage/storage.go:209:initPackages() [I] Initialising Packages storage with type: 2023/06/08 21:39:20 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at /data/gitea/packages 2023/06/08 21:39:20 routers/init.go:136:GlobalInitInstalled() [I] SQLite3 support is enabled 2023/06/08 21:39:20 routers/common/db.go:21:InitDBEngine() [I] Beginning ORM engine initialization. 2023/06/08 21:39:20 routers/common/db.go:28:InitDBEngine() [I] ORM engine initialization attempt #1/10... 2023/06/08 21:39:20 cmd/web.go:177:runWeb() [I] PING DATABASE sqlite3 2023/06/08 21:39:20 routers/init.go:141:GlobalInitInstalled() [W] Table system_setting Column version db default is , struct default is 1 2023/06/08 21:39:20 routers/init.go:141:GlobalInitInstalled() [W] Table project Column card_type db default is 0, struct default is 2023/06/08 21:39:20 routers/init.go:141:GlobalInitInstalled() [W] Table project Column card_type db nullable is false, struct nullable is true 2023/06/08 21:39:20 routers/init.go:141:GlobalInitInstalled() [W] Table hook_task has column repo_id but struct has not related field 2023/06/08 21:39:20 routers/init.go:142:GlobalInitInstalled() [I] ORM engine initialization successful! 2023/06/08 21:39:20 ...er/issues/indexer.go:156:func2() [I] PID 17: Initializing Issue Indexer: bleve 2023/06/08 21:39:20 ...er/issues/indexer.go:246:func3() [I] Issue Indexer Initialization took 1.147598ms 2023/06/08 21:39:20 ...xer/stats/indexer.go:38:populateRepoIndexer() [I] Populating the repo stats indexer with existing repositories 2023/06/08 21:39:20 ...xer/stats/indexer.go:84:populateRepoIndexer() [I] Done (re)populating the repo stats indexer with existing repositories 2023/06/08 21:39:21 cmd/web.go:235:listen() [I] Listen: http://0.0.0.0:3000 2023/06/08 21:39:21 cmd/web.go:239:listen() [I] AppURL(ROOT_URL): https://my.domain-name.fr/ 2023/06/08 21:39:21 cmd/web.go:242:listen() [I] LFS server enabled 2023/06/08 21:39:21 ...s/graceful/server.go:62:NewServer() [I] Starting new Web server: tcp:0.0.0.0:3000 on PID: 17 2023/06/08 21:40:09 ...eful/manager_unix.go:198:handleSignals() [W] PID 17. Received SIGTERM. Shutting down... 2023/06/08 21:40:09 cmd/web.go:286:listen() [I] HTTP Listener: 0.0.0.0:3000 Closed 2023/06/08 21:40:09 ...eful/server_hooks.go:46:doShutdown() [I] PID: 17 Listener ([::]:3000) closed. 2023/06/08 21:40:09 .../graceful/manager.go:168:doHammerTime() [W] Setting Hammer condition 2023/06/08 21:40:10 .../graceful/manager.go:184:doTerminate() [W] Terminating 2023/06/08 21:40:10 ...er/issues/indexer.go:183:2() [I] PID: 17 Issue Indexer closed 2023/06/08 21:40:10 ...eful/manager_unix.go:208:handleSignals() [W] PID: 17. Background context for manager closed - context canceled - Shutting down... 2023/06/08 21:40:10 cmd/web.go:197:runWeb() [I] PID: 17 Gitea Web Finished ``` ### Gitea Version 1.20.0+rc0 built with GNU Make 4.4.1, go1.20.5 : bindata, timetzdata, sqlite, sqlite_unlock_notify ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version 2.40.1, Wire Protocol Version 2 Enabled ### Operating System Synology DSM 6.2.4 build 25556 update 7 - Docker ### How are you running Gitea? `Docker image: gitea/gitea:latest` But as it is said in #25136 (which is a respawn of #21615) instead of getting a stable Docker release, last night Watchtower updated the Gitea image to a release candidate one (thus from `1.19` to `1.20.0+rc0`) ### Database SQLite
GiteaMirror added the type/bug label 2025-11-02 09:24:19 -06:00
GiteaMirror commented 2025-11-02 09:24:20 -06:00
Author
Owner
Copy Link

@jducaud commented on GitHub (Jun 8, 2023):

I am truly sorry but it seems I have been fooled by one of my own scripts... I wrote a few months ago a script called "Gitea Monitor" which monitors the git user (is it still a non-sudoer and has it still a special shell-script in its home directory as expected?) and the Gitea app.ini file (is the DISABLE_REGISTRATION parameter still true and is the SHOW_REGISTRATION_BUTTON still false as expected?).

But with this new 1.20.0+rc0 version, the syntax of the app.ini file changed. And my "Gitea Monitor" script grep and sed commands broke, leading to stop Gitea container every 5 minutes.

I should have realise that sooner. Sorry for the noise. I close this non-bug.

@jducaud commented on GitHub (Jun 8, 2023): I am truly sorry but it seems I have been fooled by one of my own scripts... I wrote a few months ago a script called "Gitea Monitor" which monitors the git user (is it still a non-sudoer and has it still a special shell-script in its home directory as expected?) and the Gitea `app.ini` file (is the `DISABLE_REGISTRATION` parameter still true and is the `SHOW_REGISTRATION_BUTTON` still false as expected?). But with this new `1.20.0+rc0` version, the syntax of the `app.ini` file changed. And my "Gitea Monitor" script `grep` and `sed` commands broke, leading to stop Gitea container every 5 minutes. I should have realise that sooner. Sorry for the noise. I close this non-bug.
GiteaMirror commented 2025-11-02 09:24:21 -06:00
Author
Owner
Copy Link

@delvh commented on GitHub (Jun 8, 2023):

But with this new 1.20.0+rc0 version, the syntax of the app.ini file changed

What do you mean?
I don't recall any such change…

@delvh commented on GitHub (Jun 8, 2023): > But with this new 1.20.0+rc0 version, the syntax of the app.ini file changed What do you mean? I don't recall any such change…
GiteaMirror commented 2025-11-02 09:24:21 -06:00
Author
Owner
Copy Link

@jducaud commented on GitHub (Jun 8, 2023):

Most of the parameters in the app.ini file had the following syntax:
PARAMETER = value(s)
I though at the time (because I did not pay attention enough) that the spaces surrounding the equal sign were important and part of the syntax.
I realise now that, even at the time I wrote my script, a few parameters had the following syntax too:
PARAMETER=value(s)
So my grep (and sed) commands broke in a silly way because my regex were too strict:

if ! grep -E '^DISABLE_REGISTRATION ' $GITEA_CONFIGURATION_FILE | grep -q 'true'; then
    stop_gitea="true"
fi

So it is a small change which should not have had consequences but did, because of my poorly written script.

@jducaud commented on GitHub (Jun 8, 2023): Most of the parameters in the `app.ini` file had the following syntax: `PARAMETER = value(s)` I though at the time (because I did not pay attention enough) that the `spaces` surrounding the `equal` sign were important and part of the syntax. I realise now that, even at the time I wrote my script, a few parameters had the following syntax too: `PARAMETER=value(s)` So my grep (and sed) commands broke in a silly way because my regex were too strict: ``` if ! grep -E '^DISABLE_REGISTRATION ' $GITEA_CONFIGURATION_FILE | grep -q 'true'; then stop_gitea="true" fi ``` So it is a small change which should not have had consequences but did, because of my poorly written script.
GiteaMirror commented 2025-11-02 09:24:21 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jun 8, 2023):

upgrade version will not change your app.ini automatically

@lunny commented on GitHub (Jun 8, 2023): upgrade version will not change your app.ini automatically
GiteaMirror commented 2025-11-02 09:24:21 -06:00
Author
Owner
Copy Link

@jducaud commented on GitHub (Jun 8, 2023):

I think it will if you have, as I do, all your app.ini parameters set via the docker-compose.yml file environment variables...

@jducaud commented on GitHub (Jun 8, 2023): I think it will if you have, as I do, all your app.ini parameters set via the docker-compose.yml file environment variables...
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#10995
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?