Mailing List Archive

I had the same issue in FreeBSD, getting mod_python working. THen I
found a somewhat obscure workaround. I know OBSD is a little different
but if you are familiar you might be able to figure out where you would
need the change.

in /usr/local/sbin/envvars I had to append:
LD_PRELOAD=/usr/lib/libc_r.so ## libc_r.so may be named libpthread.so
export LD_PRELOAD

and restart apache and I got it working in both 4.x and 5.x. Also since
your problem stems from mod_python on OBSD maybe the mod_python mailing
list and or OBSD list(s)

cheers,
reed

PS: if you can se any new messages on the mod_python list let me know.
It seems to have a problems. I haven't seen a new message on there
since the 14th.
Patrick YU wrote:

> Hello all. Is there any plan for FastCGI support (www.fastcgi.com)
> ? The reason is that
> [] mod_python requires python to have thread disabled on OpenBSD (see
> http://archives.neohapsis.com/archives/openbsd/2003-05/1776.html). I
> tried once on my alpha OpenBSD 3.5, with Python compiled with thread
> enabled, and httpd dumped core. Due to the claim I did not look further.
>
> [] now trac seems to require thread when using under mod_python
> environment ? Am I interpreting the following trace correctly ?
> Thanks in advance. -- Patrick
>
> Mod_python error: "PythonHandler trac.ModPythonHandler"
> Traceback (most recent call last):
> File "/usr/local/lib/python2.3/site-packages/mod_python/apache.py",
> line 181, in Dispatch
> module = import_module(module_name, _req)
> File "/usr/local/lib/python2.3/site-packages/mod_python/apache.py",
> line 335, in import_module
> module = imp.load_module(mname, f, p, d)
> File
> "/usr/local/lib/python2.3/site-packages/trac/ModPythonHandler.py",
> line 23, in ?
> import re, threading
> File "/usr/local/lib/python2.3/threading.py", line 6, in ?
> import thread
> ImportError: No module named thread
>
> _______________________________________________
> Trac mailing list
> Trac@lists.edgewall.com
> http://lists.edgewall.com/mailman/listinfo/trac

On Friday, June 18, 2004, at 02:37 AM, Reed L. O'Brien wrote:

> I had the same issue in FreeBSD, getting mod_python working. THen I
> found a somewhat obscure workaround. I know OBSD is a little
> different but if you are familiar you might be able to figure out where
> you would need the change.
>
> in /usr/local/sbin/envvars I had to append:
> LD_PRELOAD=/usr/lib/libc_r.so ## libc_r.so may be named libpthread.so
> export LD_PRELOAD
>
> and restart apache and I got it working in both 4.x and 5.x. Also
> since your problem stems from mod_python on OBSD maybe the mod_python
> mailing list and or OBSD list(s)

Thanks for your reply Reed. Actually, the mod_python part on my DEC
alpha seems to be working -- it has passed the "Hello World" test that
came with the mod_python 2.7.10 distribution.

The part I don't get is if the Trac's mod_python support requires
mod_python to have thread enabled, which is what I've interpreted in the
following Python traceback.

I'm now stuck with the expensive Python start-up everytime I click on my
web browser. Any suggestion ?
I was happy to discover the standalone tracd [version 0.7.1]. It ran
fine for a few requests, but core-dumped on a request for detail of my
changeset #2 (the 'diff' against the previous version request).

regards, Patrick

> Patrick YU wrote:
>
>> Hello all. Is there any plan for FastCGI support
>> (www.fastcgi.com) ? The reason is that
>> [] mod_python requires python to have thread disabled on OpenBSD (see
>> http://archives.neohapsis.com/archives/openbsd/2003-05/1776.html). I
>> tried once on my alpha OpenBSD 3.5, with Python compiled with thread
>> enabled, and httpd dumped core. Due to the claim I did not look
>> further.
>>
>> [] now trac seems to require thread when using under mod_python
>> environment ? Am I interpreting the following trace correctly ?
>> Thanks in advance. -- Patrick
>>
>> Mod_python error: "PythonHandler trac.ModPythonHandler"
>> Traceback (most recent call last):
>> File "/usr/local/lib/python2.3/site-packages/mod_python/apache.py",
>> line 181, in Dispatch
>> module = import_module(module_name, _req)
>> File "/usr/local/lib/python2.3/site-packages/mod_python/apache.py",
>> line 335, in import_module
>> module = imp.load_module(mname, f, p, d)
>> File "/usr/local/lib/python2.3/site-
>> packages/trac/ModPythonHandler.py", line 23, in ?
>> import re, threading
>> File "/usr/local/lib/python2.3/threading.py", line 6, in ?
>> import thread
>> ImportError: No module named thread

On Friday, June 18, 2004, at 10:13 AM, Patrick YU wrote:

> Thanks for your reply Reed. Actually, the mod_python part on my DEC
> alpha seems to be working -- it has passed the "Hello World" test that
> came with the mod_python 2.7.10 distribution.
>
> The part I don't get is if the Trac's mod_python support requires
> mod_python to have thread enabled, which is what I've interpreted in
> the following Python traceback.
>
> I'm now stuck with the expensive Python start-up everytime I click on
> my web browser. Any suggestion ?
> I was happy to discover the standalone tracd [version 0.7.1]. It ran
> fine for a few requests, but core-dumped on a request for detail of my
> changeset #2 (the 'diff' against the previous version request).

Well, I looked further. It seems even the basic functionality of Trac
requires Python being thread-enabled -- http://svn/cgi-
bin/trac.cgi/changeset/2 failed with some "resource
error message". I tried soft-linking dummy_thread.* to thread.* just
for fun.

Also tracd have the same 'missing thread' issue:
----------------------------------------
Exception happened during processing of request from ('192.168.1.39',
49749)
Traceback (most recent call last):
File "/usr/local/lib/python2.3/SocketServer.py", line 222, in
handle_request
self.process_request(request, client_address)
File "/usr/local/lib/python2.3/SocketServer.py", line 471, in
process_request
import threading
File "/usr/local/lib/python2.3/threading.py", line 6, in ?
import thread
ImportError: No module named thread
----------------------------------------


On the same box I recompiled Python with thread enabled, then the
subversion Python binding. The change set detail works again.

I'm confused because I can't find any thread.* files under the lib/
directory, even after compiling Python with thread.

Anyhow I think I'm stuck with the CGI access to Trac for now.

PS: I've actually tried mod_python with the now Python-with-thread, and
it did not dump core, but with error

[Fri Jun 18 16:24:28 2004] [notice] Apache/1.3.29 (Unix)
mod_python/2.7.10 Python/2.3.3 mod_ssl/2.8.16 OpenSSL/0.9.7c
configured -- resuming normal operations
[Fri Jun 18 16:24:28 2004] [notice] Accept mutex: sysvsem (Default:
sysvsem)

make_obcallback(): could not import mod_python.apache.
make_obcallback(): could not call init.
[Fri Jun 18 16:24:45 2004] [error] [client 192.168.1.39] python_handler:
make_obcallback returned no obCallBack!
---- snip

I may look at fastcgi when I have time.

regards, Patrick

On Wednesday 16 June 2004 10:38 pm, Patrick YU wrote:
> Hello all. Is there any plan for FastCGI support (www.fastcgi.com) ?

We haven't planned it for pre-1.0, and I believe you're the first to actually
mention it too btw. :)

It's not a bad idea though. FastCGI is a quite nice architecture, and might
make good sense when you wish to 'accelerate' Trac on non-Apache environments
without using tracd.

Making a FastCGI adapter should be quite straightforward for anyone willing to
take an early stab at it.

Cheers,

--
Daniel Lundin | Edgewall Software
daniel@edgewall.com | Professional Linux & Open Source Consulting
| http://www.edgewall.com/

On Wednesday 16 June 2004 10:38 pm, Patrick YU wrote:
> Hello all. Is there any plan for FastCGI support (www.fastcgi.com) ?

We haven't planned it for pre-1.0, and I believe you're the first to actually
mention it too btw. :)

It's not a bad idea though. FastCGI is a quite nice architecture, and might
make good sense when you wish to 'accelerate' Trac on non-Apache environments
without using tracd.

Making a FastCGI adapter should be quite straightforward for anyone willing to
take an early stab at it.

Cheers,

--
Daniel Lundin | Edgewall Software
daniel@edgewall.com | Professional Linux & Open Source Consulting
| http://www.edgewall.com/