On Wednesday, 5. December 2012 at 08:39, C Anthony Risinger wrote: > 512 seems pretty small to me; it should be noted that the default pipe > buffer on Linux is 8x larger.
Yep, it is small. But I didn't find a way to change it on OS X. Setting it with ulimit -p yields: -bash: ulimit: pipe size: cannot modify limit: Invalid argument It turns out that these limits are managed by launchd, but there's no mention of pipe in what seems to be the corresponding limit docs: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/launchctl.1.html http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/setrlimit.2.html#//apple_ref/doc/man/2/setrlimit (http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/setrlimit.2.html%23//apple_ref/doc/man/2/setrlimit) I've been fairly happy with the closeness of OS X to Unix right until now. :) > alas, it seems the stdout pipe buffer is filling faster than uWSGI is > emptying it for whatever reason... uWSGI calls `setlinebuf(stdout)` at > core/uwsgi.c:1736, *unconditionally* setting stdout to line buffered > -- maybe try removing this line, or setting to > unbuffered/fully-buffered -- as python apparantly attempts a > non-blocking write, full-buffered via libc (vs. kernel/native) might > be necessary. Thanks for the hint. Replacing that line with: setbuf(stdout, (char*)malloc(32768)); I no longer get any "Message too long" errors. I do get "IOError: [Errno 55] No buffer space available" errors for large messages, but in those cases a truncated version of the log message does get printed before the error, and the truncated message is always either 1024, 2048, 3072 or 4096 bytes (randomly picked): DEBUG 262144 bytes XXXXXXXX[...]XXXXXXXXTraceback (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 (where I've replaced a lot of Xes with [...]) This is the case even when I log really large messages (I tried up to 16777216 bytes); I always get at least the first 1024 bytes, and never more than 4096 bytes. This remains the case when I try a bigger stdout buffer. Oh, and logging.raiseExceptions = False didn't do anything useful, it just stopped the errors from being displayed. That Python bug is about writing to a socket (presumably a syslog datagram socket) but the underlying reason may be the same Mac OS X buffer strangeness. Gulli
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
