Open brdw opened 7 years ago
I am able to reproduce the error with the files above, here are the uwsgi logs:
$ uwsgi --http :8080 --ini conf.ini --mount /=server:app --req-logger file:requests.log
[uWSGI] getting INI configuration from conf.ini
*** Starting uWSGI 2.0.15 (64bit) on [Mon Aug 21 10:46:54 2017] ***
compiled with version: 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42) on 17 August 2017 16:07:45
os: Darwin-16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64
nodename: btaba
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 4
current working directory: /Users/btaba/uwsgi-367
detected binary path: /Users/btaba/anaconda/bin/uwsgi
your processes number limit is 709
your memory page size is 4096 bytes
detected max file descriptor number: 256
lock engine: OSX spinlocks
thunder lock: disabled (you can enable it with --thunder-lock)
uWSGI http bound on :8080 fd 9
uwsgi socket 0 bound to TCP address xxxx (port auto-assigned) fd 8
Python version: 3.6.0 |Anaconda 4.3.0 (x86_64)| (default, Dec 23 2016, 13:19:00) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x7fa4b6801800
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 145504 bytes (142 KB) for 1 cores
*** Operational MODE: single process ***
mounting server:app on /
WSGI app 0 (mountpoint='/') ready in 0 seconds on interpreter 0x7fa4b6801800 pid: 64648 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 64648)
spawned uWSGI worker 1 (pid: 64649, cores: 1)
spawned uWSGI http 1 (pid: 64650)
And the file permissions
$ ls -alh
-rw-r--r-- 1 btaba staff 28B Aug 21 10:38 conf.ini
-rw-r----- 1 btaba staff 191B Aug 21 10:47 requests.log
-rw-r--r-- 1 btaba staff 128B Aug 21 10:38 server.py
This still seems to be happing. Any idea of how to deal with it? I have tried everything I can think of without any luck...
You can just use tee to redirect stdout/stderr to a log file instead of using --req-logger
...
instead of logger I solved this issue by using logto
Bump...
On uwsgi 2.0.19.logfile-chmod works with
logto, but not with
logger = file:...`.
But using logto
means that, as far as I can see, I can't have other loggers (e.g. stdout) used as well.
yes, this is still an issue with latest uwsgi. logfile-chmod
does not seems to apply to the logger-req
file. same with logger-maxsize
. this makes logger-req
a very limited option...
i managed to use an exec
hook and it worked.
logger = file:logfile=uwsgi.log,maxsize=10240
logger-req = file:logfile=uwsgi_access.log,maxsize=10240
hook-as-user = exec:chmod 644 uwsgi.log
hook-as-user = exec:chmod 644 uwsgi_access.log
unfortunately the file rotation then creates the new logfile with the strict mode again...
i tried setting umask=022
but this seems to affect only files created by the app running under uwsgi, not its own files.
I ran into the same issues with rotated files having the wrong permissions, and logfile-chmod not applying to my logfile based logger.
I just added a cron task to clean up the permissions every minute for every file that isn't readable.
unique-cron = -1 -1 -1 -1 -1 find /path/to/log/dir -type f -a \! -perm -a=r -exec chmod a+r {} \;
I'm having issues getting logging file permissions to work with uwsgi. This is important because we have a companion fluend container trying to ship this log file to and ELK stack but it can't access the files from uwsgi.
I made a simple flask app called server.py
I then made a uwsgi conf.ini file. There isn't really any documentation on what are acceptable values to pass into this, but I saw someone else online try this.
I'm starting up the server with this command
However when I hit the server and get requests I don't see the file permissions set correctly.
This is on a mac, running python 3.5 with uWSGI==2.0.15