Thanks Roberto. Confirm that solves the bytes/string issue. I now notice an issue (possibly unrelated) where nginx fails to find the unix-socket when uwsgi is run from the commandline like below; following running uwsgi in this way it becomes necessary to delete ``/var/run/uwsgi.pid`` and ``/tmp/uwsgi.sock`` in order for uwsgi to be started by rc.d.
Full trace: [simonyarde@howarth-dev] $ sudo uwsgi --ini-paste development.ini [uWSGI] getting INI configuration from development.ini *** Starting uWSGI 1.3-dev (64bit) on [Fri Jul 20 00:52:42 2012] *** compiled with version: 4.2.1 20070831 patched [FreeBSD] on 20 July 2012 00:00:26 os: FreeBSD-9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 [email protected]:/usr/obj/usr/src/sys/GENERIC nodename: howarth-dev machine: amd64 detected number of CPU cores: 1 current working directory: /usr/local/virtenv/hwa-0.2/hwa detected binary path: /usr/local/bin/uwsgi uWSGI running as root, you can use --uid/--gid/--chroot options *** WARNING: you are running uWSGI as root !!! (use the --uid flag) *** your memory page size is 4096 bytes detected max file descriptor number: 11095 lock engine: POSIX semaphores uwsgi socket 0 bound to UNIX address /tmp/uwsgi.sock fd 3 Python version: 3.2.3 (default, Jul 11 2012, 10:17:04) [GCC 4.2.1 20070831 patched [FreeBSD]] Set PythonHome to /usr/local/virtenv/hwa-0.2 *** Python threads support is disabled. You can enable it with --enable-threads *** Python main interpreter initialized at 0x8031240c0 your server socket listen backlog is limited to 100 connections *** Operational MODE: single process *** Loading paste environment: config:/usr/local/virtenv/hwa-0.2/hwa/development.ini ****** SY DEBUG ****** uri: str ***** END SY DEGUG ***** ****** SY DEBUG ****** uri: str ***** END SY DEGUG ***** WSGI app 0 (mountpoint='') ready in 2 seconds on interpreter 0x8031240c0 pid: 36074 (default app) *** uWSGI is running in multiple interpreter mode *** spawned uWSGI master process (pid: 36074) spawned uWSGI worker 1 (pid: 36081, cores: 1) ^CSIGINT/SIGQUIT received...killing workers... goodbye to uWSGI. On 19 Jul 2012, at 06:44, Roberto De Ioris wrote: > >> Realised I might have knocked this question out of the public >> consciousness by replying to my own post with some additional info... Here >> it is collated into a single (more considered) post. >> >> >> I have a situation where uWSGI is attempting to load the paste >> environment, and ``uri`` in deploy's ``loadcontext`` is bytes whereas I >> believe it should be string, resulting in: >> >> TypeError: Type str doesn't support the buffer API >> >> I have modified my Deploy to coerce ``uri`` to a string and uWSGI then >> launches successfully. This issue does not occur with Pyramid's waitress >> server reading the same .ini file (see trace). >> >> Is this an issue with uWSGI sending the wrong type, or should Paste Deploy >> be more tolerant of bytes/strings in this case? >> >> Best, S >> >> >> > > > Can you try with that patch ? > > https://github.com/unbit/uwsgi/commit/2de9b9d5c7269fd255da75cc10d6565722cbd6a7 > > > > -- > Roberto De Ioris > http://unbit.it > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
