Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default to logging to stdout/stderr under systemd #6987

Closed
silverwind opened this issue May 19, 2019 · 9 comments
Closed

Default to logging to stdout/stderr under systemd #6987

silverwind opened this issue May 19, 2019 · 9 comments
Labels
issue/stale type/docs This PR mainly updates/creates documentation

Comments

@silverwind
Copy link
Member

We get a number of issues like #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?

@lunny
Copy link
Member

lunny commented May 19, 2019

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

@zeripath
Copy link
Contributor

zeripath commented 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 zeripath reopened this May 19, 2019
@silverwind
Copy link
Member Author

silverwind commented 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.

@lafriks lafriks added the type/docs This PR mainly updates/creates documentation label May 20, 2019
@zeripath
Copy link
Contributor

zeripath commented 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 #6095 in the Subloggers section and https://docs.gitea.io/en-us/config-cheat-sheet/#log-subsections-log-name-log-name

@silverwind
Copy link
Member Author

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

[log.console]
LEVEL =
STDERR = true

@zeripath
Copy link
Contributor

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.

@silverwind
Copy link
Member Author

silverwind commented 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.

@stale
Copy link

stale bot commented 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 stale bot added the issue/stale label Jul 19, 2019
@stale
Copy link

stale bot commented Aug 2, 2019

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

@stale stale bot closed this as completed Aug 2, 2019
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/stale type/docs This PR mainly updates/creates documentation
Projects
None yet
Development

No branches or pull requests

4 participants