search

ramkrishanbhatt / modwsgi

Automatically exported from code.google.com/p/modwsgi
0 stars 0 forks source link

strange behaviour when using display-name #175

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Hi,

I just tracked down a problem with cx_Oracle that is only happening when
run under mod_wsgi. A simple cx_Oracle.connect will work or fail just
changing mod_wsgi configuration:

Inside Apache virtualhost config:
WSGIDaemonProcess mygroup user=www-data group=www-data processes=1
threads=10 inactivity-timeout=60

Result:
DEBUG - Cursor: <__builtin__.OracleCursor on <cx_Oracle.Connection to
xxxx@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.xxx.xx)(POR
T=xxxx)))(CONNECT_DATA=(SID=XXXX)))>>

Next, only display-name is added:
WSGIDaemonProcess mygroup user=www-data group=www-data processes=1
threads=10 inactivity-timeout=60 display-name=%{GROUP}

Result:
ERROR - ORA-06413: Connection not open.

The error does not show when running the same code under the command line
(i.e. python26 test_oracle.py)

Here is the code:
try:
    import cx_Oracle
    dsn = cx_Oracle.makedsn('192.168.0.1', '1521', 'SID')
    connection = cx_Oracle.connect("user", "password", dsn)
    cursor = connection.cursor()
    import logging
    logging.debug("Cursor: " + repr(cursor))
except Exception, e:
    import logging
    logging.error(e)

Original issue reported on code.google.com by manelclos@gmail.com on 22 Jan 2010 at 12:41

GoogleCodeExporter commented 8 years ago 
Can you try the following values in succession and indicate if any work?

1. Give path that actually exists.

  display-name=/usr/bin/python

2. Give absolute path but where doesn't exit.

  display-name=/usr/bin/wsgi

3. Don't use brackets.

  display-name=wsgi

Want to see if the issue is simply that it is being changed, or that it expects 
it to refer to a valid path to a file that 
exists.

Original comment by Graham.Dumpleton@gmail.com on 24 Jan 2010 at 11:06

GoogleCodeExporter commented 8 years ago

Original comment by Graham.Dumpleton@gmail.com on 24 Jan 2010 at 11:07

GoogleCodeExporter commented 8 years ago 
Graham,
I am experiencing this same issue as well in attempting to deploy a django web 
app
which uses cx_Oracle to connect to the db layer.  Here is the results for the 
values
you suggested:

From Original Bug Report:
1) No display name results in no exception
1) display-name=%{GROUP} results in reported exception

From Requested Follow up:
1) display-name=/usr/bin/python results in no exception (though this isn't the 
python
I'm using)
2) display-name=/usr/bin/wsgi results in no exception
3) display-name=wsgi results in no exception

Other:
1) display-name=/usr/local/bin/python2.6 results in no exception (this is the 
path to
the python I'm using)

Original comment by MarkRo...@gmail.com on 3 Mar 2010 at 7:45

GoogleCodeExporter commented 8 years ago 
Not sure if it is import, but I should probably note this just in case.  I 
changed
the original line in the bug report:
WSGIDaemonProcess mygroup user=www-data group=www-data processes=1
threads=10 inactivity-timeout=60

To:
WSGIDaemonProcess mygroup user=apache group=apache processes=1 threads=10
inactivity-timeout=60

So as to reflect the user/group that my apache process is running under.

Original comment by MarkRo...@gmail.com on 3 Mar 2010 at 7:48

GoogleCodeExporter commented 8 years ago 
Are you able to say whether this causes a problem:

  display-name=(wsgi:mygroup)

This is what:

  display-name=%{GROUP}

would be equivalent to.

If doing same explicitly causes an issue, then it must be the content, ie., 
presence of certain characters, which 
is the problem. If it works, then may be the processing of %{GROUP} itself.

Original comment by Graham.Dumpleton@gmail.com on 4 Mar 2010 at 3:50

GoogleCodeExporter commented 8 years ago 
What versions of mod_wsgi are you all using?

If it is mod_wsgi 3.X, one possibility of why this is causing an issue is 
because initialisation of Python interpreter 
is now deferred until after daemon processes are forked. A consequence of this 
is likely that interpreter is 
initialised after mod_wsgi has fiddled argv[0] based on the display-name 
option. This will mean that sys.argv[0] 
in Python will be that value where as in mod_wsgi <3.0 that wouldn't be the 
case as argv[0] fiddled after Python 
interpreter initialised.

Now, if the Oracle wrapper C code is doing something with sys.argv[0] and isn't 
expecting to see odd characters 
in their like brackets or colon, then maybe that is why it is blowing up.

So, if using mod_wsgi 3.X, try with mod_wsgi 2.8 and see if still get problem 
there.

Original comment by Graham.Dumpleton@gmail.com on 4 Mar 2010 at 10:25

GoogleCodeExporter commented 8 years ago 
Graham,
I think you found the issue right there.  Apparently ORA-06413 most often 
occurs when
the executable has parens in its path (see link below).  I'll install 2.8 to 
see if I
can confirm if this is the case.

http://www.dba-oracle.com/t_ora_06413_connection_not_open.htm

Original comment by MarkRo...@gmail.com on 5 Mar 2010 at 8:37

GoogleCodeExporter commented 8 years ago 
I installed 2.8 and it actually still caused the issue (if it makes any 
difference I
pulled it from the subversion tag as downloads from google-code are throwing 
404s). 
I did check your other suggestion on using what the %{GROUP} expands to and 
here are
my results:

display-name=(wsgi:mygroup)
Caused the exception

display-name=wsgi:mygroup
No Exception

display-name=(wsgimygroup)
Caused the exception

So at this point I'm pretty sold on the issue being the paren characters.  

-Mark

Original comment by MarkRo...@gmail.com on 5 Mar 2010 at 9:22

GoogleCodeExporter commented 8 years ago 
All I can see that I can do is document this in the Application Issues 
document. Will do that when get a chance to 
catch up on some of the documentation.

Original comment by Graham.Dumpleton@gmail.com on 9 Mar 2010 at 10:51

GoogleCodeExporter commented 8 years ago 
Added some notes in:

http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Oracle_Wrappers

warning about this.

Not much else that can do but warn about problem.

Original comment by Graham.Dumpleton@gmail.com on 10 Mar 2010 at 10:05

GoogleCodeExporter commented 8 years ago 
Thanks Graham.  This sounds like the best solution (since it's really an Oracle 
problem).

-Mark

Original comment by MarkRo...@gmail.com on 13 Mar 2010 at 12:40

GoogleCodeExporter commented 8 years ago 
I believe I'm getting the same issue using Apache 2.2 on Windows. 
Unfortunately, since the daemon mode is unavailable, I can't set the 
WSGIDaemonprocess directive to override a group name. I'm not sure if my 
understanding of the issue is correct, but it seems to me that this can't be 
fixed using some Apache directives on Windows. Is that correct?

Original comment by deepu.su...@gmail.com on 17 Jun 2010 at 8:22

GoogleCodeExporter commented 8 years ago 
This issue in mod_wsgi cannot affect Windows as mod_wsgi doesn't override 
argv[0] on Windows at any time. Any problem on Windows is going to be due to 
something other than this.

Original comment by Graham.Dumpleton@gmail.com on 17 Jun 2010 at 10:59

GoogleCodeExporter commented 8 years ago 
Did you check here?
http://www.dba-oracle.com/t_ora_06413_connection_not_open.htm

There's a couple of reasons you could see that error.

Original comment by MarkRo...@gmail.com on 18 Jun 2010 at 12:08