It's the rc that is installed from FreeBSD ports.. think it could use updating in various ways. Note it is hardwired for Python2 because there are no config options, and you can only run it with the default build-profile.
I'll try creating my own along the lines you suggest and see how I get along. On 21 Jul 2012, at 06:50, Roberto De Ioris wrote: > >> 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. >> > > > This could be a problem with your rc script. > > uWSGI does not make checks about file overwrites. You may want to add the > vacuum option to clear the file generated by uWSGI, but i suggest you (if > possibile) to modify your rc script to use the --flock option to avoid > multiple instances of the same app accidentally running (instead of > checking for file existance) > >> >> 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 >> > > > -- > 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
