> > From: C Anthony Risinger <[email protected]>
> 
> > 
> > while im unsure the "correctness" of your setup, have you tried
> > `--log-master`, `--threaded-logger` (IIRC the latter implies former),
> > and related `--log-*` options? we use a setup resembling this:
> > 
> > 
> 
> 

> > From: Roberto De Ioris <[email protected]>
> > Yes, you should not do that as you are generating doubled logs.

Thanks both! That sounds good. But a couple of questions:

1. "as you are generating doubled logs" -- hm? How do you mean doubled? I have 
not been getting duplicate log messages.

2. when I try this on Mac OS X 10.8.2, I get errors like this for log messages 
2kb and bigger:

Traceback (most recent call last):
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/logging/__init__.py",
 line 797, in emit
    stream.write(fs % msg)
IOError: [Errno 40] Message too long


even when the log message is just 5354 bytes and I run with 
--log-master-bufsize 1048576.

The cutoff seems to be around 2048 bytes but it's not consistent which error I 
get, or even fully consistent ("monotonous with log message size") whether the 
error happens. I made a hack view that logs a message with each byte size from 
2040 to 2051 (exact length of formatted string passed to stream.write in 
logging/__init__.py:797 including newline):

   DEBUG 2040 bytes 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX...
   DEBUG 2041 bytes 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX...
   DEBUG 2042 bytes 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX...
   DEBUG 2043 bytes 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX...
   DEBUG 2044 bytes 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX...
Traceback (most recent call last):
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/logging/__init__.py",
 line 797, in emit
    stream.write(fs % msg)
IOError: [Errno 55] No buffer space available
   DEBUG 2046 bytes 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX...
   DEBUG 2047 bytes 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX...
   DEBUG 2048 bytes 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX...
Traceback (most recent call last):
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/logging/__init__.py",
 line 797, in emit
    stream.write(fs % msg)
IOError: [Errno 40] Message too long
Traceback (most recent call last):
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/logging/__init__.py",
 line 797, in emit
    stream.write(fs % msg)
IOError: [Errno 40] Message too long
Traceback (most recent call last):
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/logging/__init__.py",
 line 797, in emit
    stream.write(fs % msg)
IOError: [Errno 40] Message too long


>From a few trials, it seems that:

* 2041 bytes and less always works
* 2042-2048 bytes inconsistently either works or fails with "[Errno 55] No 
buffer space available"
* 2049 bytes and up always fails with "[Errno 40] Message too long"
* I've seen one case of neither the log message nor any error (that one was 
2048 bytes)

This is when running on Mac OS X 10.8.2. Does not happen on my Linux servers. 
The uwsgi version is 1.4.2.

Trying to figure this out, I took a look at ulimit -a:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 256
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 709
virtual memory          (kbytes, -v) unlimited


But the pipe size here is 512 bytes, too small for any of these messages, so 
that doesn't seem to explain this.

Any ideas?

Regards,

Gulli

_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to