Gitea stop without any message if redis is not available #3159

New Issue

GiteaMirror · 2025-11-02T05:02:20-06:00

GiteaMirror commented

2025-11-02 05:02:20 -06:00

Originally created by @3l73 on GitHub (Apr 9, 2019).

Gitea version (or commit ref): 1.7
Git version: N/A
Operating system: Linux
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
- Redis
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

No log information.

Description

Redis is used as indexer queue. In case the redis service is not up and running, gitea would not start.
This currently did not lead to any log entries (syslog or gitea log) or other informations.
In case gitea is start by hand, no error information is shown on the terminal.

Originally created by @3l73 on GitHub (Apr 9, 2019). - Gitea version (or commit ref): 1.7 - Git version: N/A - Operating system: Linux - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - [x] Redis - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [ ] Not relevant - Log gist: No log information. ## Description Redis is used as indexer queue. In case the redis service is not up and running, gitea would not start. This currently did not lead to any log entries (syslog or gitea log) or other informations. In case gitea is start by hand, no error information is shown on the terminal.

GiteaMirror added the type/bug label 2025-11-02 05:02:20 -06:00

GiteaMirror closed this issue

2025-11-02 05:02:20 -06:00

GiteaMirror commented

2025-11-02 05:02:21 -06:00

@zeripath commented on GitHub (Apr 9, 2019):

This is due to the output of log.Fatal never actually being printed before os.Exit() is called in modules/log/log.go. This is fixed in #6095 - which will be in 1.9.

Edit: I should say although the message is added to the queue - no time is given to finish emptying the queue.

@zeripath commented on GitHub (Apr 9, 2019): This is due to the output of `log.Fatal` never actually being printed before `os.Exit()` is called in `modules/log/log.go`. This is fixed in #6095 - which will be in 1.9. Edit: I should say although the message is added to the queue - no time is given to finish emptying the queue.

GiteaMirror commented

2025-11-02 05:02:21 -06:00

@zeripath commented on GitHub (Apr 9, 2019):

The log.Fatal in particular is at:

https://github.com/go-gitea/gitea/blob/master/routers/init.go#L95

@zeripath commented on GitHub (Apr 9, 2019): The `log.Fatal` in particular is at: https://github.com/go-gitea/gitea/blob/master/routers/init.go#L95

GiteaMirror commented

2025-11-02 05:02:21 -06:00

@zeripath commented on GitHub (Apr 9, 2019):

I don't think we can realistically backport the new logging infrastructure to 1.8 (or 1.7 for that matter).

If really required a simple hacky fix would be to change the level of the log to log.Critical and then panic(), or possibly replace the os.Exit in log.Fatal with a panic()

@zeripath commented on GitHub (Apr 9, 2019): I don't think we can realistically backport the new logging infrastructure to 1.8 (or 1.7 for that matter). If really required a simple hacky fix would be to change the level of the log to `log.Critical` and then `panic()`, or possibly replace the `os.Exit` in `log.Fatal` with a `panic()`

GiteaMirror commented

2025-11-02 05:02:21 -06:00

@lunny commented on GitHub (Apr 9, 2019):

@zeripath I also don't think it's necessary to back port that PR.

@lunny commented on GitHub (Apr 9, 2019): @zeripath I also don't think it's necessary to back port that PR.

GiteaMirror commented

2025-11-02 05:02:22 -06:00

@zeripath commented on GitHub (Apr 9, 2019):

OK I think I'll close this issue as the issue is already fixed.

@zeripath commented on GitHub (Apr 9, 2019): OK I think I'll close this issue as the issue is already fixed.

GiteaMirror referenced this issue

2025-11-02 12:19:30 -06:00