Uwsgi: Python 3 and stdout

[joaodlf]

All of my uwsgi logs are being output to stderr. Essentially, I share the exact same problem as explained here: https://stackoverflow.com/questions/44977066/logging-stdout-with-python3-and-uwsgi

My supervisord setup:

[program:analytics_uwsgi]
command=/var/env/bin/uwsgi --ini /var/current/uwsgi.ini
autostart=true
autorestart=true
stopsignal=QUIT
stdout_logfile=/var/uwsgi_logs/stdout.log
stdout_logfile_backups=5
stderr_logfile=/var/uwsgi_logs/stderr.log
stderr_logfile_backups=5

uwsgi ini file:

[uwsgi]
http = 127.0.0.1:8000
home = env
wsgi-file = autoapp.py
callable = app
master = true
reload-mercy = 10
worker-reload-mercy = 10
enable-threads = true
processes = 4
threads = 2
touch-reload = /var/web/uwsgi.pid
chdir = /var/web/current
virtualenv = /var/env/
pidfile = /var/web/uwsgi.pid
socket = /var/web/uwsgi_analytics.sock
chmod-socket = 777
vacuum = true
stats = :8001
stats-http = true
buffer-size = 32768

I have read the following: http://lists.unbit.it/pipermail/uwsgi/2016-January/008353.html , does this relate to https://uwsgi-docs.readthedocs.io/en/latest/Options.html#shared-pyimport ? And if so, what is a possible example of a fix?

[joaodlf]

I'm wondering if there is any possible extra insight into this? Something I could possibly be overlooking or extra info I might need to share?

[bhavya0692]

Any solution for workaround for this issue ?

[baspenny]

A year has been past.. Any update would be nice.

[unbit]

Hi, as explained in the mailing-list post, if you need to split stdout and stderr, just remap their file descriptors using python code executed on startup. They (fd: 1 and 2) point to the same resource, but if you are forced to supervisord and need to split them, the only solution is closing and reopening the related files.

Take into account that you have the 'python' logger too, if instead of using unix file descriptor you prefer the python logging subsystem.

Or, well you could remove supervisord from the stack :)

[zeusttu]

Thank you for your response! Some help might be appreciated to find the relevant mailing list post though. I grepped through the logs from January 2017 to August 2018 and did not find anything resembling this issue. I am kind of curious about this idea of reopening the stdout file descriptor to reroute stdout to the true stdout, it sounds kind of like something that should not be possible and which I probably misunderstood.

By the way, in case it matters, our reason to want stdout-writes to end up at stdout is because our log handlers are configured to write messages of severity INFO or lower to stdout and WARNING or higher to stderr, and the cloud platform the application runs on looks whether a message was printed to stdout or stderr in order to determine the severity (there is sadly no way to make it look for [INFO], [WARNING] and [ERROR]). So currently all our log messages show up as errors.

[zakkg3]

delegate the login process to master solved the problem for me.

--log-master
https://github.com/unbit/uwsgi/blob/d960f8fdc36b33c60b7291ca8e32dbb5df22cf15/core/uwsgi.c#L794

[Andres-GC]

Thank you for your response! Some help might be appreciated to find the relevant mailing list post though. I grepped through the logs from January 2017 to August 2018 and did not find anything resembling this issue. I am kind of curious about this idea of reopening the stdout file descriptor to reroute stdout to the true stdout, it sounds kind of like something that should not be possible and which I probably misunderstood.

By the way, in case it matters, our reason to want stdout-writes to end up at stdout is because our log handlers are configured to write messages of severity INFO or lower to stdout and WARNING or higher to stderr, and the cloud platform the application runs on looks whether a message was printed to stdout or stderr in order to determine the severity (there is sadly no way to make it look for [INFO], [WARNING] and [ERROR]). So currently all our log messages show up as errors.

@zeusttu Did you find a way to solve the issue?

[zeusttu]

@zeusttu Did you find a way to solve the issue?

I worked as a contractor on the system having the issue at the time. I no longer work there, so I don't know if the issue persists 😅