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

log to console by default #832

Closed
tlatorre-uchicago opened this Issue Jul 29, 2014 · 13 comments

Comments

Projects
None yet
7 participants
@tlatorre-uchicago

tlatorre-uchicago commented Jul 29, 2014

I was trying to debug an issue with gunicorn failing to start, and so I tried running it in console, but it would fail silently. I spent roughly an hour before finding this stack overflow question http://stackoverflow.com/questions/24222608/gunicorn-not-starting-workers and noticed that gunicorn is not set to print to console by default. What is the rationale behind this?

I imagine that most users will not see this question, or end up at the FAQ (http://docs.gunicorn.org/en/latest/faq.html#why-i-don-t-see-any-logs-in-the-console), and this will cause many hours of debugging. Is there a very strong reason for this that outweighs this potential confusion by most users?

@benoitc

This comment has been minimized.

Show comment
Hide comment
@benoitc

benoitc Aug 1, 2014

Owner

the reason is that most of the time gunicorn will be launched via a supervisor. In that case you don't want to see the logs in the stdout/stderr generally. I wonder what other think?

Owner

benoitc commented Aug 1, 2014

the reason is that most of the time gunicorn will be launched via a supervisor. In that case you don't want to see the logs in the stdout/stderr generally. I wonder what other think?

@romabysen

This comment has been minimized.

Show comment
Hide comment
@romabysen

romabysen Aug 1, 2014

Contributor

Doesn't most supervisors capture stdout/stderr for this very purpose though? Upstart, Heroku, Foreman/honcho & daemontools/runit all captures the output of the supervised process for logging. At least in my case the times you want to log to console greatly outnumbers the times you want it to be silent.

Contributor

romabysen commented Aug 1, 2014

Doesn't most supervisors capture stdout/stderr for this very purpose though? Upstart, Heroku, Foreman/honcho & daemontools/runit all captures the output of the supervised process for logging. At least in my case the times you want to log to console greatly outnumbers the times you want it to be silent.

@mlavin

This comment has been minimized.

Show comment
Hide comment
@mlavin

mlavin Aug 1, 2014

I was caught by this change in R19 and found it somewhat annoying mostly because I'm having to back through the chapters of our upcoming book where we were expecting this output by default (originally written against R18). It's already been noted in some submitted errata and emailed feedback. People seem to get the impression that when there is no output that it is "just hanging". That might be because the book implies there will be output. It isn't hard to explain how to enable the console logging but I agree that I expect it by default.

mlavin commented Aug 1, 2014

I was caught by this change in R19 and found it somewhat annoying mostly because I'm having to back through the chapters of our upcoming book where we were expecting this output by default (originally written against R18). It's already been noted in some submitted errata and emailed feedback. People seem to get the impression that when there is no output that it is "just hanging". That might be because the book implies there will be output. It isn't hard to explain how to enable the console logging but I agree that I expect it by default.

@tilgovi

This comment has been minimized.

Show comment
Hide comment
@tilgovi

tilgovi Aug 1, 2014

Collaborator

I think stderr is probably the right default log.

Collaborator

tilgovi commented Aug 1, 2014

I think stderr is probably the right default log.

@benoitc

This comment has been minimized.

Show comment
Hide comment
@benoitc

benoitc Aug 8, 2014

Owner

@tilgovi do you mean logging by default to stderr? what about info log?

@romabysen most servers don't log in the console event in frontend. Take for example nginx. Not saying we should not revert it though.

Owner

benoitc commented Aug 8, 2014

@tilgovi do you mean logging by default to stderr? what about info log?

@romabysen most servers don't log in the console event in frontend. Take for example nginx. Not saying we should not revert it though.

@benoitc

This comment has been minimized.

Show comment
Hide comment
@benoitc

benoitc Aug 8, 2014

Owner

@mlavin hrm sorry for the inconvenience it caused. The change has ben done long time ago in master without review (a0ccfa0) . I am still undecided on what to do but since it forced us to add an FAQ maybe we should revert it indeed.

Owner

benoitc commented Aug 8, 2014

@mlavin hrm sorry for the inconvenience it caused. The change has ben done long time ago in master without review (a0ccfa0) . I am still undecided on what to do but since it forced us to add an FAQ maybe we should revert it indeed.

@mlavin

This comment has been minimized.

Show comment
Hide comment
@mlavin

mlavin Aug 8, 2014

@benoitc don't worry about my inconvenience. I'm being paid to write. Just passing on feedback. You all should do whatever you feel is best for the future of Gunicorn. Thank you all for your work.

mlavin commented Aug 8, 2014

@benoitc don't worry about my inconvenience. I'm being paid to write. Just passing on feedback. You all should do whatever you feel is best for the future of Gunicorn. Thank you all for your work.

@tilgovi

This comment has been minimized.

Show comment
Hide comment
@tilgovi

tilgovi Aug 14, 2014

Collaborator

@benoitc What about log to stderr by default unless daemonizing. If there's a controlling TTY we log to it.

Collaborator

tilgovi commented Aug 14, 2014

@benoitc What about log to stderr by default unless daemonizing. If there's a controlling TTY we log to it.

@benoitc

This comment has been minimized.

Show comment
Hide comment
@benoitc

benoitc Aug 14, 2014

Owner

@tilgovi what would be the advantage over writing to stdout? Thinking of it since it's a problem for a lot of people we should probably put back the logging to console unless it's disable (and provide a way to disable it).

Owner

benoitc commented Aug 14, 2014

@tilgovi what would be the advantage over writing to stdout? Thinking of it since it's a problem for a lot of people we should probably put back the logging to console unless it's disable (and provide a way to disable it).

@tilgovi

This comment has been minimized.

Show comment
Hide comment
@tilgovi

tilgovi Aug 14, 2014

Collaborator

I don't care either way much about stdout or stderr but stderr is what I
thought was the common default for such things.

Although, it's different when you have an application that's expected to
print output AND log internals and errors. With a service like gunicorn,
there is only one type of output.

Although, we could log on stderr and just print a "Gunicorn is running"
message with the bind address on stdout.

I don't know. Your call. I'm just giving ideas.
On Aug 14, 2014 12:33 PM, "Benoit Chesneau" notifications@github.com
wrote:

@tilgovi https://github.com/tilgovi what would be the advantage over
writing to stdout? Thinking of it since it's a problem for a lot of people
we should probably put back the logging to console unless it's disable (and
provide a way to disable it).


Reply to this email directly or view it on GitHub
#832 (comment).

Collaborator

tilgovi commented Aug 14, 2014

I don't care either way much about stdout or stderr but stderr is what I
thought was the common default for such things.

Although, it's different when you have an application that's expected to
print output AND log internals and errors. With a service like gunicorn,
there is only one type of output.

Although, we could log on stderr and just print a "Gunicorn is running"
message with the bind address on stdout.

I don't know. Your call. I'm just giving ideas.
On Aug 14, 2014 12:33 PM, "Benoit Chesneau" notifications@github.com
wrote:

@tilgovi https://github.com/tilgovi what would be the advantage over
writing to stdout? Thinking of it since it's a problem for a lot of people
we should probably put back the logging to console unless it's disable (and
provide a way to disable it).


Reply to this email directly or view it on GitHub
#832 (comment).

@benoitc

This comment has been minimized.

Show comment
Hide comment
@benoitc

benoitc Aug 14, 2014

Owner

@tilgovi I like the last suggestion ! We could definitely does that. And print a message to tell how to have logging on the console. I will work on that tomorrow!

Owner

benoitc commented Aug 14, 2014

@tilgovi I like the last suggestion ! We could definitely does that. And print a message to tell how to have logging on the console. I will work on that tomorrow!

@collinanderson

This comment has been minimized.

Show comment
Hide comment
@collinanderson

collinanderson Sep 10, 2014

Contributor

heroku, upstart, supervisord and systemd will all automatically log both stdout and stderror. Automatically logging to stdout or stderr really simplifies configuration and it makes it really easy for beginners to know what's going on.

If you don't have logging to the console by default, you run "gunicorn myapp:application" for the first time and have no idea that it's listening on http://127.0.0.1:8000. Or, you run it and it hangs for 5 seconds and stops with no feedback because something else is already using the port. By default, gunicorn should tell you what the problem is.

Contributor

collinanderson commented Sep 10, 2014

heroku, upstart, supervisord and systemd will all automatically log both stdout and stderror. Automatically logging to stdout or stderr really simplifies configuration and it makes it really easy for beginners to know what's going on.

If you don't have logging to the console by default, you run "gunicorn myapp:application" for the first time and have no idea that it's listening on http://127.0.0.1:8000. Or, you run it and it hangs for 5 seconds and stops with no feedback because something else is already using the port. By default, gunicorn should tell you what the problem is.

collinanderson added a commit to collinanderson/gunicorn that referenced this issue Sep 16, 2014

Log to stderr by default. #832
Version 19 removed any logging by default. This logs everything to
stderr by default.

collinanderson added a commit to collinanderson/gunicorn that referenced this issue Sep 16, 2014

Log to stderr by default. #832
Version 19 removed any logging by default. This logs everything to
stderr by default.

collinanderson added a commit to collinanderson/gunicorn that referenced this issue Sep 16, 2014

Log to console by default. #832
Version 19 removed any logging by default. This logs everything to
console by default.

collinanderson added a commit to collinanderson/gunicorn that referenced this issue Sep 16, 2014

Log to console by default. #832
Version 19 removed any logging by default. This logs everything to the
console by default.

collinanderson added a commit to collinanderson/gunicorn that referenced this issue Sep 22, 2014

Log to console by default. #832
Version 19 removed any logging by default. This logs everything to the
console by default.

collinanderson added a commit to collinanderson/gunicorn that referenced this issue Sep 22, 2014

Log to console by default. #832
Version 19 removed any logging by default. This logs everything to the
console by default.

collinanderson added a commit to collinanderson/gunicorn that referenced this issue Sep 22, 2014

Log to console by default. #832
Version 19 removed any logging by default. This logs everything to the
console by default.

collinanderson added a commit to collinanderson/gunicorn that referenced this issue Sep 22, 2014

Log to console by default. #832
Version 19 removed any logging by default. This logs everything to the
console by default.

collinanderson added a commit to collinanderson/gunicorn that referenced this issue Sep 22, 2014

Log to console by default. #832
Version 19 removed any logging by default. This logs everything to the
console by default.

benoitc added a commit that referenced this issue Sep 22, 2014

Merge pull request #892 from collinanderson/logconsole
Proposal: Log to console by default. #832
@berkerpeksag

This comment has been minimized.

Show comment
Hide comment
@berkerpeksag

berkerpeksag Sep 22, 2014

Collaborator

This is done now: 7be15d6

Collaborator

berkerpeksag commented Sep 22, 2014

This is done now: 7be15d6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment