Send fatal errors to console & provide more better information when they occur #2132

New Issue

GiteaMirror · 2025-11-02T04:25:00-06:00

GiteaMirror commented

2025-11-02 04:25:00 -06:00

Originally created by @MTecknology on GitHub (Aug 2, 2018).

When starting, gitea will sometimes attempt to write/re-write app.ini. This causes problems when trying to build a debian package. It's also against the "best practice" of restricting the data an application can manipulate to only what's needed.

I think that gitea should instead:

Generate a warning for unset values with suitable defaults, and provide the default
Use the default instead of crashing
Generate an error for unset required values with no suitable default (and fail to start)
Not attempt to write the default

Perhaps the behavior could be to only attempt writing a config for a new install, or if gitea has write access. The important thing is that Gitea should not consider the inability to edit app.ini an error or even a warning.

Originally created by @MTecknology on GitHub (Aug 2, 2018). When starting, gitea will sometimes attempt to write/re-write app.ini. This causes problems when trying to build a debian package. It's also against the "best practice" of restricting the data an application can manipulate to only what's needed. I think that gitea should instead: - Generate a warning for unset values with suitable defaults, and provide the default - Use the default instead of crashing - Generate an error for unset required values with no suitable default (and fail to start) - Not attempt to write the default Perhaps the behavior could be to only attempt writing a config for a new install, or if gitea has write access. The important thing is that Gitea should not consider the inability to edit app.ini an error or even a warning.

GiteaMirror added the type/proposal type/enhancement labels 2025-11-02 04:25:00 -06:00

GiteaMirror closed this issue

2025-11-02 04:25:00 -06:00

GiteaMirror commented

2025-11-02 04:25:00 -06:00

@lafriks commented on GitHub (Aug 2, 2018):

By crashing do you mean just exits or there are real crash?

It can not continue as otherwise either lfs will not work or openssh integration

@lafriks commented on GitHub (Aug 2, 2018): By crashing do you mean just exits or there are real crash? It can not continue as otherwise either lfs will not work or openssh integration

GiteaMirror commented

2025-11-02 04:25:00 -06:00

@MTecknology commented on GitHub (Aug 11, 2018):

By crash, I meant it did not start and produced no message. It looks like part of the problem was with an older version. With what was released today, I get an almost useful message buried in the logs.

I see that this is considered a "fatal" error, but the error was not logged to the console even though it caused an immediate exit.

Another thought- It would also be nice if the message included exactly what parameter was required rather than just describing the parameter. For instance, "Error saving generated JWT Secret to custom config" does not say that the parameter that needs to be set is "LFS_JWT_SECRET". It also doesn't say that this can be generated by the user. A more useful message could be "LFS_JWT_SECRET was unset but is required to continue. A generated value could not be written to the configuration file. Please generate a value or allow gitea to write to the configuration file."
Of course, there's probably a more terse way to convey that information.

The point I'm attempting to make is that many of the fatal errors don't seem to indicate what they really mean and don't show up on the console unless all logging is directed to the console. Unfortunately, this means messages won't be visible to something like "service gitea status" when gitea is run as a proper service. When the message is found in the log, it's unclear how the problem should be resolved.

@MTecknology commented on GitHub (Aug 11, 2018): By crash, I meant it did not start and produced no message. It looks like part of the problem was with an older version. With what was released today, I get an almost useful message buried in the logs. I see that this is considered a "fatal" error, but the error was not logged to the console even though it caused an immediate exit. Another thought- It would also be nice if the message included exactly what parameter was required rather than just describing the parameter. For instance, "Error saving generated JWT Secret to custom config" does not say that the parameter that needs to be set is "LFS_JWT_SECRET". It also doesn't say that this can be generated by the user. A more useful message could be "LFS_JWT_SECRET was unset but is required to continue. A generated value could not be written to the configuration file. Please generate a value or allow gitea to write to the configuration file." Of course, there's probably a more terse way to convey that information. The point I'm attempting to make is that many of the fatal errors don't seem to indicate what they really mean and don't show up on the console unless all logging is directed to the console. Unfortunately, this means messages won't be visible to something like "service gitea status" when gitea is run as a proper service. When the message is found in the log, it's unclear how the problem should be resolved.

GiteaMirror commented

2025-11-02 04:25:01 -06:00

@zeripath commented on GitHub (May 31, 2019):

I think this is fixed now - Fatal Errors will actually be logged due to log.Close() occurring before the os.Exit().

@zeripath commented on GitHub (May 31, 2019): I think this is fixed now - Fatal Errors will actually be logged due to log.Close() occurring before the os.Exit().

GiteaMirror referenced this issue

2025-11-02 12:05:55 -06:00

[PR #2132] [MERGED] Use POSIX complaint ! operator in find #16249

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#2132