How do I configure the ROUTER logger in 1.16? #8709

New Issue

GiteaMirror · 2025-11-02T08:15:08-06:00

GiteaMirror commented

2025-11-02 08:15:08 -06:00

Originally created by @mjevans on GitHub (Mar 16, 2022).

Gitea Version

v1.16.4 built with GNU Make 4.1, go1.17.8 : bindata, sqlite, sqlite_unlock_notify

Git Version

n/a

Operating System

Arch Linux - gitea binary downloaded from gitea.io

How are you running Gitea?

The systemd unit provided with the archlinux install of gitea

Database

SQLite

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Description

Since I can't reopen #19105

I've skimmed https://docs.gitea.io/en-us/logging-configuration/ for any keywords that seem remotely relevant and tried every sort of logging configuration I can think of. Even when everything is set to Critical only the logs still needlessly record every get and put, twice.

I'd still like to capture any output that indicates a problem might exist, but to help me see if a problem exists I want the haystack to be smaller. The Started GET Completed GET status lines are surely supposed to be INFO level right? Or maybe there's some specific logging facility that isn't obvious?

++

The Archlinux package was already marked stale, and while I updated the git sha hash to checkout in the build script it doesn't produce a working package; probably missing or incorrect build dependencies.

So I grabbed a binary from the site and dropped it over the broken gitea that had been installed.

A new comment has been added to the old gist; the problem persists.

https://gist.github.com/mjevans/cee0ec30575b53e77668ba9fc1cf1be2

Mar 16 08:48:11 gitea gitea[39656]: 2022/03/16 08:48:11 ...dules/setting/log.go:283:newLogService() [I] Gitea v1.16.4 built with GNU Make 4.1, go1.17.8 : bindata, sqlite, sqlite_unlock_notify

It's also unclear what log facility is generating any of these lines. They're prefixed go logging timestamps, the pid, an additional timestamp, and then the message. No indication of the facility or log level like traditional syslog entries.

Screenshots

No response

Originally created by @mjevans on GitHub (Mar 16, 2022). ### Gitea Version v1.16.4 built with GNU Make 4.1, go1.17.8 : bindata, sqlite, sqlite_unlock_notify ### Git Version n/a ### Operating System Arch Linux - gitea binary downloaded from gitea.io ### How are you running Gitea? The systemd unit provided with the archlinux install of gitea ### Database SQLite ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Description Since I can't reopen #19105 I've skimmed https://docs.gitea.io/en-us/logging-configuration/ for any keywords that seem remotely relevant and tried every sort of logging configuration I can think of. Even when everything is set to Critical only the logs still needlessly record every get and put, twice. I'd still like to capture any output that indicates a problem might exist, but to help me see if a problem exists I want the haystack to be smaller. The Started GET Completed GET status lines are surely supposed to be INFO level right? Or maybe there's some specific logging facility that isn't obvious? ++ The Archlinux package was already marked stale, and while I updated the git sha hash to checkout in the build script it doesn't produce a working package; probably missing or incorrect build dependencies. So I grabbed a binary from the site and dropped it over the broken gitea that had been installed. A new comment has been added to the old gist; the problem persists. https://gist.github.com/mjevans/cee0ec30575b53e77668ba9fc1cf1be2 Mar 16 08:48:11 gitea gitea[39656]: 2022/03/16 08:48:11 ...dules/setting/log.go:283:newLogService() [I] Gitea v1.16.4 built with GNU Make 4.1, go1.17.8 : bindata, sqlite, sqlite_unlock_notify It's also unclear what log facility is generating any of these lines. They're prefixed go logging timestamps, the pid, an additional timestamp, and then the message. No indication of the facility or log level like traditional syslog entries. ### Screenshots _No response_

GiteaMirror added the type/question label 2025-11-02 08:15:08 -06:00

GiteaMirror closed this issue

2025-11-02 08:15:09 -06:00

GiteaMirror commented

2025-11-02 08:15:09 -06:00

@zeripath commented on GitHub (Mar 16, 2022):

The STARTED/COMPLETED lines are ROUTER lines.

https://docs.gitea.io/en-us/logging-configuration/#the-router-logger

@zeripath commented on GitHub (Mar 16, 2022): The STARTED/COMPLETED lines are ROUTER lines. https://docs.gitea.io/en-us/logging-configuration/#the-router-logger

GiteaMirror commented

2025-11-02 08:15:10 -06:00

@zeripath commented on GitHub (Mar 16, 2022):

When discussing Logging you need to show us your configuration too. So what is your logging configuration?

@zeripath commented on GitHub (Mar 16, 2022): When discussing Logging you need to show us your configuration too. So what is your logging configuration?

GiteaMirror commented

2025-11-02 08:15:10 -06:00

@mjevans commented on GitHub (Mar 16, 2022):

They even show up at Critical level, unless I'm setting that incorrectly. Which might be likely since the documentation appears to reflect v1.17 which I earlier incorrectly thought I was running given the shipped version of go (1.17.8).

I'm currently working around this by adding the DISABLE_ROUTER_LOG line, but I probably want to have it set to WARN instead of getting all of the spam from the TRACE and INFO levels which are exposed even with the current config absent the disable toggle.

[log]
MODE             = console
LEVEL            = Error
DISABLE_ROUTER_LOG = true
ROUTER           = console
ROUTER_LOG_LEVEL = Error
ENABLE_ACCESS_LOG = false
ENABLE_XORM_LOG = false
ACCESS          = none
ACCESS_LOG_LEVEL = Critical
ROOT_PATH        = /var/lib/gitea/log

@mjevans commented on GitHub (Mar 16, 2022): They even show up at Critical level, unless I'm setting that incorrectly. Which might be likely since the documentation appears to reflect v1.17 which I earlier incorrectly thought I was running given the shipped version of go (1.17.8). I'm currently working around this by adding the DISABLE_ROUTER_LOG line, but I probably want to have it set to WARN instead of getting all of the spam from the TRACE and INFO levels which are exposed even with the current config absent the disable toggle. ```ini [log] MODE = console LEVEL = Error DISABLE_ROUTER_LOG = true ROUTER = console ROUTER_LOG_LEVEL = Error ENABLE_ACCESS_LOG = false ENABLE_XORM_LOG = false ACCESS = none ACCESS_LOG_LEVEL = Critical ROOT_PATH = /var/lib/gitea/log ```

GiteaMirror commented

2025-11-02 08:15:10 -06:00

@zeripath commented on GitHub (Mar 16, 2022):

I cannot understand from your comments what you want.

DISABLE_ROUTER_LOG: Disables the router logger and all of its subloggers so you will never get any router logs
ROUTER_LOG_LEVEL: Sets the level that the ROUTER log messages are logged at - not what level the logger will print. (I appreciate this may be somewhat counter-intuitive however, it had to be that way to keep it backwards compatible with the configuration from 1.7.)
By setting you ROUTER = console you have sent router messages to the console sublogger.
The configuration for the console sublogger of the router logger is determined by the following hierarchy:
- [log.console.router]
- [log.console]
- [log]
If there is no MODE in [log.console.router] or [log.console] the type of the logger will a console logger.
If there is no LEVEL in [log.console.router] or [log.console] the LEVEL it will log at will be the [log] LEVEL.

Thus by setting the ROUTER_LOG_LEVEL to ERROR and the main log level to ERROR you've guaranteed that router messages will always appear.

Could you explain clearly what you want?

@zeripath commented on GitHub (Mar 16, 2022): I cannot understand from your comments what you want. * `DISABLE_ROUTER_LOG`: Disables the router logger and all of its subloggers so you will never get any router logs * `ROUTER_LOG_LEVEL`: Sets the level that the ROUTER log messages are **logged** at - not what level the logger will print. (I appreciate this may be somewhat counter-intuitive however, it had to be that way to keep it backwards compatible with the configuration from 1.7.) * By setting you `ROUTER = console` you have sent router messages to the `console` sublogger. * The configuration for the `console` sublogger of the router logger is determined by the following hierarchy: - `[log.console.router]` - `[log.console]` - `[log]` * If there is no MODE in `[log.console.router]` or `[log.console]` the type of the logger will a `console` logger. * If there is no LEVEL in `[log.console.router]` or `[log.console]` the LEVEL it will log at will be the `[log]` `LEVEL`. Thus by setting the ROUTER_LOG_LEVEL to ERROR and the main log level to ERROR you've guaranteed that router messages will always appear. --- Could you explain clearly what you want?

GiteaMirror commented

2025-11-02 08:15:10 -06:00

@zeripath commented on GitHub (Mar 16, 2022):

My suspicion is that you simply need:

[log]
MODE = console
LEVEL = error

@zeripath commented on GitHub (Mar 16, 2022): My suspicion is that you simply need: ```ini [log] MODE = console LEVEL = error ```

GiteaMirror commented

2025-11-02 08:15:11 -06:00

@mjevans commented on GitHub (Mar 16, 2022):

I didn't realize what I wanted last night, the documentation is confusing and unclear if someone isn't familiar with the source code.

A) I do not want are the Router logger's TRACE and INFO level events.
B) I would, at least until I have real world data, find Router WARN level events desirable.

This suggestion clearly fulfills A, but seems unlikely to fulfill B.

[log]
MODE = console
LEVEL = error

Some of the configuration came from a template shipped with an older version of Gitea; I think it had a list of the log levels as well as some directives for the log section that are absent on the live documentation. https://docs.gitea.io/en-us/logging-configuration/

[log]
MODE             = console
LEVEL            = Error

[log.console.router]
LEVEL            = WARN

Will the above do B while avoiding A? It doesn't appear to accept WARNING (which is the RFC 5424 syntax) and appears to silently default to debug when given "WARNING" as it's level... which is how I know that it will fill my logs with the undesired 'TRACE' (debug?) and 'INFO' levels from the documentation.

The live documentation could be improved with:

An enumeration of log levels. They appear similar to RFC 5424 / syslog style levels https://en.wikipedia.org/wiki/Syslog#Severity_level

Log Groups are at the top, then expanded over the page. It would be more clearly reflected if it had the 'default' logger as the root of a tree, with the three other loggers bullet points beneath it.

"sublogger" needs it's own section and/or should be more clearly a stand-in such as OUTPUTSTREAM (which should be stylized differently than values / variables, and maybe hyperlink to the section describing the possible streams). In several spots log.sublogger.X are highlighted; but sublogger is never defined anywhere. Having slept on it, I happened to notice log.console in the Empty Configuration summary of the defaults.

@mjevans commented on GitHub (Mar 16, 2022): I didn't realize what I wanted last night, the documentation is confusing and unclear if someone isn't familiar with the source code. A) I do _not_ want are the Router logger's TRACE and INFO level events. B) I would, at least until I have real world data, find Router WARN level events desirable. This suggestion clearly fulfills A, but seems unlikely to fulfill B. ```ini [log] MODE = console LEVEL = error ``` Some of the configuration came from a template shipped with an older version of Gitea; I think it had a list of the log levels as well as some directives for the log section that are absent on the live documentation. https://docs.gitea.io/en-us/logging-configuration/ ```ini [log] MODE = console LEVEL = Error [log.console.router] LEVEL = WARN ``` Will the above do B while avoiding A? It doesn't appear to accept WARNING (which is the RFC 5424 syntax) and appears to silently default to debug when given "WARNING" as it's level... which is how I know that it will fill my logs with the undesired 'TRACE' (debug?) and 'INFO' levels from the documentation. The live documentation could be improved with: An enumeration of log levels. They appear similar to RFC 5424 / syslog style levels https://en.wikipedia.org/wiki/Syslog#Severity_level Log Groups are at the top, then expanded over the page. It would be more clearly reflected if it had the 'default' logger as the root of a tree, with the three other loggers bullet points beneath it. "sublogger" needs it's own section and/or should be more clearly a stand-in such as OUTPUTSTREAM (which should be stylized differently than values / variables, and maybe hyperlink to the section describing the possible streams). In several spots log.sublogger.X are highlighted; but sublogger is never defined anywhere. Having slept on it, I happened to notice log.console in the Empty Configuration summary of the defaults.

GiteaMirror commented

2025-11-02 08:15:11 -06:00

@zeripath commented on GitHub (Mar 16, 2022):

There are no "WARN" router events.

The router simply logs request start and end.

@zeripath commented on GitHub (Mar 16, 2022): There are no "WARN" router events. The router simply logs request start and end.

GiteaMirror commented

2025-11-02 08:15:11 -06:00

@mjevans commented on GitHub (Mar 16, 2022):

The current documentation does mention slow and failed routers. (Should "failed" be at Error level instead?)

https://docs.gitea.io/en-us/logging-configuration/#the-router-logger

...

slow routers will be logged at WARN
failed routers will be logged at WARN

@mjevans commented on GitHub (Mar 16, 2022): The current documentation does mention slow and failed routers. (Should "failed" be at Error level instead?) https://docs.gitea.io/en-us/logging-configuration/#the-router-logger ... slow routers will be logged at WARN failed routers will be logged at WARN

GiteaMirror commented

2025-11-02 08:15:12 -06:00

@zeripath commented on GitHub (Mar 16, 2022):

That is referring to changes made in 1.17

@zeripath commented on GitHub (Mar 16, 2022): That is referring to changes made in 1.17

GiteaMirror commented

2025-11-02 08:15:12 -06:00

@mjevans commented on GitHub (Mar 16, 2022):

I'll re-iterate "The live documentation could be improved":

Configuration items that are invalid should be FATAL, possibly deferred until the end of configuration parse. (This is 'documentation' in the form of the program enforcing syntax and providing useful error messages.)

Enumerate accepted log levels. It would also be nice if accepted log levels included accepted values from RFC 5424 https://datatracker.ietf.org/doc/html/rfc5424#page-11 / syslog https://en.wikipedia.org/wiki/Syslog#Severity_level

In the "Log Groups" section the 'default' logger should be the root of a tree, with the three other loggers bullet points beneath it.

An OUTPUT STREAMS section or similar should be added. "sublogger" (E.G. log.sublogger.X ) and similar should be replaced with a hyperlink to that section and a more descriptive name.

The 'empty' configuration should be renamed Default configuration and expanded...

[log]
ROOT_PATH = %(GITEA_WORK_DIR)/log
MODE = console
LEVEL = Info
STACKTRACE_LEVEL = None
ENABLE_ACCESS_LOG = false
ENABLE_XORM_LOG = true
XORM = ,

[log.console]
MODE = console
LEVEL = %(log.LEVEL)
STACKTRACE_LEVEL = %(log.STACKTRACE_LEVEL)
FLAGS = stdflags
PREFIX =
COLORIZE = true # Or false if your windows terminal cannot color

[log.console.router]
LEVEL = %(log.console.LEVEL)
...

[log.console.access]
LEVEL = %(log.console.LEVEL)
...

[log.console.xorm]
LEVEL = %(log.console.LEVEL)
...

BTW is it intended to allow different log LEVELs across OUTPUTs?

[log.console.router]
LEVEL = WARN
...

[log.file.router]
LEVEL = Notice
...

[log.conn.router]
LEVEL = INFO

; mail
[log.smtp.router]
LEVEL = Critical
...

@mjevans commented on GitHub (Mar 16, 2022): I'll re-iterate "The live documentation could be improved": Configuration items that are invalid should be FATAL, possibly deferred until the end of configuration parse. (This is 'documentation' in the form of the program enforcing syntax and providing useful error messages.) Enumerate accepted log levels. It would also be nice if accepted log levels included accepted values from RFC 5424 https://datatracker.ietf.org/doc/html/rfc5424#page-11 / syslog https://en.wikipedia.org/wiki/Syslog#Severity_level In the "Log Groups" section the 'default' logger should be the root of a tree, with the three other loggers bullet points beneath it. An OUTPUT STREAMS section or similar should be added. "sublogger" (E.G. log.sublogger.X ) and similar should be replaced with a hyperlink to that section and a more descriptive name. The 'empty' configuration should be renamed Default configuration and expanded... ```ini [log] ROOT_PATH = %(GITEA_WORK_DIR)/log MODE = console LEVEL = Info STACKTRACE_LEVEL = None ENABLE_ACCESS_LOG = false ENABLE_XORM_LOG = true XORM = , [log.console] MODE = console LEVEL = %(log.LEVEL) STACKTRACE_LEVEL = %(log.STACKTRACE_LEVEL) FLAGS = stdflags PREFIX = COLORIZE = true # Or false if your windows terminal cannot color [log.console.router] LEVEL = %(log.console.LEVEL) ... [log.console.access] LEVEL = %(log.console.LEVEL) ... [log.console.xorm] LEVEL = %(log.console.LEVEL) ... ``` BTW is it intended to allow different log LEVELs across OUTPUTs? ```ini [log.console.router] LEVEL = WARN ... [log.file.router] LEVEL = Notice ... [log.conn.router] LEVEL = INFO ; mail [log.smtp.router] LEVEL = Critical ... ```

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#8709