Default to logging to stdout/stderr under systemd #3352

New Issue

GiteaMirror · 2025-11-02T05:09:35-06:00

GiteaMirror commented

2025-11-02 05:09:35 -06:00

Originally created by @silverwind on GitHub (May 19, 2019).

We get a number of issues like https://github.com/go-gitea/gitea/issues/6972 with no usable error information because apparently gitea does not log anything to the stdout and stderr when it encounters runtime errors. I'm not sure how these deployments are done, but I assume log.mode does not include console?

Originally created by @silverwind on GitHub (May 19, 2019). We get a number of issues like https://github.com/go-gitea/gitea/issues/6972 with no usable error information because apparently gitea does not log anything to the `stdout` and `stderr` when it encounters runtime errors. I'm not sure how these deployments are done, but I assume `log.mode` does not include `console`?

GiteaMirror added the issue/stale type/docs labels 2025-11-02 05:09:35 -06:00

GiteaMirror closed this issue

2025-11-02 05:09:35 -06:00

GiteaMirror commented

2025-11-02 05:09:36 -06:00

@lunny commented on GitHub (May 19, 2019):

log.mode default will record nothing if you ignore that setting I think. @zeripath

@lunny commented on GitHub (May 19, 2019): log.mode default will record nothing if you ignore that setting I think. @zeripath

GiteaMirror commented

2025-11-02 05:09:36 -06:00

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

We can't detect if we're being run by systemd or not very easily - (I think if our parent is pid 0 that's probably the only way). Further people are very particular about logging so overriding them is not really acceptable.

However what we could do recommend is that the basic logging config is:

[Log]
Mode=error_console

[Log.error_console]
Mode=console
Stderr=true
Level=Error

That should at least give us something

Edit: my phone keyboard is being really annoying of late. I'm so sorry to keep closing things by mistake.

@zeripath commented on GitHub (May 19, 2019): We can't detect if we're being run by systemd or not very easily - (I think if our parent is pid 0 that's probably the only way). Further people are very particular about logging so overriding them is not really acceptable. However what we could do recommend is that the basic logging config is: ``` [Log] Mode=error_console [Log.error_console] Mode=console Stderr=true Level=Error ``` That should at least give us something Edit: my phone keyboard is being really annoying of late. I'm so sorry to keep closing things by mistake.

GiteaMirror commented

2025-11-02 05:09:36 -06:00

@silverwind commented on GitHub (May 20, 2019):

Yes, no need to detect systemd, this is purely about documentation. I think we should adjust our app.ini.sample to include error logging on stderr.

What is this error_console mode? It seems undocumented.

@silverwind commented on GitHub (May 20, 2019): Yes, no need to detect systemd, this is purely about documentation. I think we should adjust our `app.ini.sample` to include error logging on stderr. What is this `error_console` mode? It seems [undocumented](https://github.com/go-gitea/gitea/blob/8de76b6e646e91c41143242dc0a8d3ae05b35023/custom/conf/app.ini.sample#L538).

GiteaMirror commented

2025-11-02 05:09:37 -06:00

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

You can name a logger whatever you like, the mode will default to the name if you don't provide it.

The ability to do this was mentioned here https://github.com/go-gitea/gitea/pull/6095 in the Subloggers section and https://docs.gitea.io/en-us/config-cheat-sheet/#log-subsections-log-name-log-name

@zeripath commented on GitHub (May 20, 2019): You can name a logger whatever you like, the mode will default to the name if you don't provide it. The ability to do this was mentioned here https://github.com/go-gitea/gitea/pull/6095 in the Subloggers section and https://docs.gitea.io/en-us/config-cheat-sheet/#log-subsections-log-name-log-name

GiteaMirror commented

2025-11-02 05:09:37 -06:00

@silverwind commented on GitHub (May 20, 2019):

I see. Why not just change the default for the console logger to include stderr?

[log.console]
LEVEL =
STDERR = true

@silverwind commented on GitHub (May 20, 2019): I see. Why not just change the default for the `console` logger to include stderr? ```` [log.console] LEVEL = STDERR = true ````

GiteaMirror commented

2025-11-02 05:09:37 -06:00

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

It's best to keep stderr for errors only. If you use [log.console] to configure that logger, then if you want to add a console logger for easy debugging then it becomes more difficult.

It doesn't really matter I guess - it's supposed to be configurable.

@zeripath commented on GitHub (May 20, 2019): It's best to keep stderr for errors only. If you use [log.console] to configure that logger, then if you want to add a console logger for easy debugging then it becomes more difficult. It doesn't really matter I guess - it's supposed to be configurable.

GiteaMirror commented

2025-11-02 05:09:37 -06:00

@silverwind commented on GitHub (May 20, 2019):

Ah, so the console logger is bound to only log to stdout if it has STDERR=false? In that case, your suggestion makes sense. Should we then define two default loggers, console and error_console to get both streams properly attached?

Generally, I think the logger configuration, while flexible, is a bit too complex for regular users to understand.

@silverwind commented on GitHub (May 20, 2019): Ah, so the `console` logger is bound to only log to `stdout` if it has `STDERR=false`? In that case, your suggestion makes sense. Should we then define two default loggers, `console` and `error_console` to get both streams properly attached? Generally, I think the logger configuration, while flexible, is a bit too complex for regular users to understand.

GiteaMirror commented

2025-11-02 05:09:38 -06:00

@stale[bot] commented on GitHub (Jul 19, 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 (Jul 19, 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 05:09:38 -06:00

@stale[bot] commented on GitHub (Aug 2, 2019):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Aug 2, 2019): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror referenced this issue

2025-11-02 12:21:45 -06:00

[PR #3352] [MERGED] Address issues pointed out by @lunny in #3339 #16902

Sign in to join this conversation.