Mod_Python + Django library import issue - python

I recently had a site that was running perfect for months, all of a sudden it decided to dump itself for no approximate reason.
I am running django + mod_python + apache, and the system decided it was time to start ignoring the import of the pycurl library, my intial first thought was that somehow the library had become corrupted, or the paths were uncached by apache or mod_python.
After checking the paths, symbolic links, permissions and reinstalling the exact build of pycurl I am still recieving the same error. The strange thing is, is that I can load the library within python itself and run tests with no issues, but not within mod_python. I know for a fact that the paths are correctly pointed as I have checked them numerous times and updated the system cache accordingly.
Django now will not load or throw any errors, nor will apache log anything if I try and import the library it will just silently fail... I have been exploring this issue for 2 days now and have not come up with anything.
Any help would be greatly appreciated.
Just to add some here, the server has not been touched in any way since the final revision and launch.
I have checked every log that would indicate some type of attack against the server and there is nothing, the only thing that exists is request from my hosting provider which is where the error in question first started to appear.
Also the similar issue: stackoverflow.com/questions/1099981/… - does not work in this case.
Incase anyone is wondering the versions are as follows
Python 2.4.3
Mod_Python 3.2.8
Apache 2.2.3
Redhat Red Hat Enterprise Linux Server release 5.4
Linux Kernal 2.6.18-128.7.1.el5 x86_64

If the problem is a failing import when running under Apache but the import works when running from your login shell, double-check that there isn't a directory/file permission problem with the failing module(s). They must be read-accessible and in some cases also execute-accessible from the user id that Apache is running under.

The httpd process could be running into the open file limit; see help ulimit in bash for the relevant option to change.

Well now ... I have debugged this issue ... and the answer is quite surprising.
R**kspace decided to do a few updates to the box, updating the dependent library in question and it caused the issues ... after reinstalling the library it would try to load the c module and it was not a comp version with the current pycurl ... and they couldn't figure this out themselves for 2 days.

Related

Installing mesos egg for python 2.7

I've installed mesos 0.26 successfully on a vm machine.
The installation has been performed on an ubuntu trusty thar system
by following this manual:
https://open.mesosphere.com/getting-started/install/
So far so good. I wanted to write a tiny python framwork.
For this I need to install the eggs via easy_install:
(I've downloaded the eggs accordingly for the trusty thar ubuntu and the 0.26 mesos):
wget http://downloads.mesosphere.io/master/ubuntu/14.04/mesos-0.26.0-py2.7-linux-x86_64.egg
easy_install mesos-0.26.0-py2.7-linux-x86_64.egg
all went fine, however, if I start python in the shell
and type in
import mesos.interface
I get the message: ImportError: No module named interface
As someone suggested, it may be that there is no longer a binding for python, or that they have renamed the API calls. Well, I looked in the version updates here:
http://mesos.apache.org/documentation/latest/upgrades/
Since the transition from 0.19.x to 0.20.x there hasn't been any changes regarding the mesos.interface part, or at least they are not mentioning it here.
To increase the confusion I also get the following error message when I'm typing in python: import mesos.native
There I receive: ImportError: No module named interface.mesos_pb2. To put it into a nutshell: what is going wrong here, and how can it be fixed? And yes, I've googled various web pages, with terms such as "mesos python bindings", mesos +api +python, etc. And yes, I have also consulted the official mesos webpage. There are nice refences for Java and C++ but not for python, or at least they are very well hidden.
Thanks in advance for any hints.
Solved. For what reasons ever:
export PYTHONPATH=${PYTHONPATH}:/usr/lib/python2.7/site-packages/
is required to set the PYTHONPATH. After that step it works like a charm.

HTTP Error 502.2 - Bad Gateway Configuring IIS 7 with Python 2.7

I am a newbie to Stack Overflow (first post), but really see the use of this website.
I'm stumped. We are trying to setup IIS 7.0 to run with WinPython 2.7 on a Windows 7 machine.
I am an IIS newb, but veteran Python user. IIS 7 can NOT find a library, which python finds, and executes, perfectly when ran on it's own. When executed via IIS, the script fails with a traceback, and IIS returns the 502.2.
I found this thread http://forums.iis.net/p/1209465/2073173.aspx?HTTP+Error+502+2+Bad+Gateway+Frustrations but the advised solution is simply another troubleshooting suggestion.
I found IIS's description (http://support.microsoft.com/kb/942057) of the error helpful, but futile.
I found Python's start-up options/parameters helpful (http://docs.python.org/2/using/cmdline.html), but futile.
I found IIS's advice for configuring Python helpful (http://support.microsoft.com/kb/276494, but (questionably?) incomplete.
This thread on manually defining an alternate bin folder (http://forums.asp.net/t/1303052.aspx?Tell+IIS+to+load+dll+from+another+directory+not+Bin+web+config+) might be where my solution lies, but I don't think it is because of the fact that this all worked on 2.6 without doing that to IIS.
IIS seems to allow python to import any module that is just a python script. As soon as it gets to a *.pyd (basically just python's version of a dll file) file, it screams. I'm no pro when it comes to DLLs and windows environments, but wouldn't IIS have to have paths to a bin folder of some kind? Do I have to manually edit them, as discussed in the last link above?
ACTUAL ERROR Details below for DLL failed Load:
The Error :
" HTTP Error 502.2 - Bad Gateway The specified CGI application
misbehaved by not returning a complete set of HTTP headers. The
headers it did return are "Traceback (most recent call last): File
"\estorage.equitable.int\riskmgmt\Quants\web\LinksPage.py", line 2,
in import pyweb File
"\estorage.equitable.int\riskmgmt\Quants\Common2014\Python\pyweb__init__.py",
line 5, in from core import * File
"\estorage.equitable.int\riskmgmt\Quants\Common2014\Python\pyweb\core.py",
line 2, in from pylib import pgdb File
"\estorage.equitable.int\riskmgmt\Quants\Common2014\Python\pylib\pgdb.py",
line 8, in from scikits import timeseries as ts File
"C:\WinPython-32bit-2.7.6.2-20140401\python-2.7.6\lib\site-packages\scikits.timeseries-0.91.3-py2.7-win32.egg\scikits\timeseries__init__.py",
line 13, in import const File
"C:\WinPython-32bit-2.7.6.2-20140401\python-2.7.6\lib\site-packages\scikits.timeseries-0.91.3-py2.7-win32.egg\scikits\timeseries\const.py",
line 79, in from cseries import freq_constants ImportError:
DLL load failed: The specified module could not be found. ".
I'm confident that the python environment is configured properly, as the script runs from the same executable (python.exe) via a command line. I'm thinking that I don't have IIS configured properly, for the new Python 2.7 install. The same script worked yesterday, on IIS and python 2.6. But during our upgrade from 2.6 to 2.7, a bunch of PATH and PYTHONPATH parameters all changed, plus we went from ActivePython to WinPython. WinPython is "registered" on the machine.
What I've tried
confirming python's sys.path is as expected at run-time in both IIS and command line - it is.
using the module from python command line.
recompiling the failing module using two different compilers (ming32 and VS2008).
putting duplicates of my new 2.7 modules in the old python26 folder.
pulling out lots of hair and other hacky stuff.
My next step, is to post this same message on a python forum. If anybody can advise on a good one for python-IIS related challenges, that would be appreciated.
Please help! Thanks in advance.
I got this 502.2 error when doing a clean installation of PHP 5.5 in Windows Server 2012 R2 with IIS 8.5.
It turns out PHP is a Visual C++ application which needs the library MSVCR110.dll in order to run properly. My computer does not have Visual Studio 2012 installed and thus it does not have this file. I got my problem solved by installing the Visual C++ Redistributable Packages https://www.microsoft.com/en-us/download/details.aspx?id=30679#
(Note: jc77 is my associate, and I'm actually the OP, as this was an x-post from IIS forums.)
We solved the problem.
tl,dr; portable python + sloppy/rookie compiling = strange behaviour + frustrations.
Bottom line, compile properly. For scikits.timeseries, using ming32 everything will walk, talk, and sound like it works in Spyder.exe, but not in python.exe. You have to use VS2008, if you want it to work in both.
More Info:
Winpython (as well as others) presents itself as identical to any other python installations, if you "register" the installation. It works great, 99% of the time. We learned the hard way, that "Winpython Interpreter.exe" and "python.exe" provided in the install are in fact different. Can't explain why, but the two executables gave different behavior. We were doing all our testing in Spyder, which must use "winpython interpreter.exe". The module which IIS couldn't find, would import and run no problem in Spyder. Then, in IIS, using python.exe, the module wouldn't import. We were operating on the assumption that the IDE would use python.exe, and that the stack was identical. As, 99% of the time, they appear to be. The way we were compiling scikits worked in winpython interpreter.exe. We were making a rookie mistake when compiling scikits, but it went un-noticed because it was working fine in our IDE (Spyder).
I'm adding these keywords for others : Anybody else who receives errors like this is likely using a portable python installation AND not compiling something properly. Winpython, Portable Python, eGenix, [and possibly?] Active State and Enthought Canopy.
While trying to configure CGI to run Perl in Windows 8.1, I had HTTP Error 502.2, but then I read loste's post and solved the problem. I had previously installed both Perl64 and Strawberry Perl. Although the IIS EventHandler pointed to only the Perl64 directory, both directories appeared in my Windows PATH variable. I prefer Strawberry Perl, so I changed the EventHandler to point to the Strawberry Perl directory and deleted the paths to Perl64 from the Windows PATH variable to solve the error.
Try this
print("Content-Type: text/html\n")
print("Hello Python World!")
You must specify the type of document

Python 2.7.5 on Cygwin64: requests installation fails

Our project is a mostly J2EE based development with the automatic functional and integration tests written in Python. The test environment is Linux nonetheless developers use Windows 7 (64-bit). We would like to be able to execute the functional tests on the developer machines as well (before comitting). Unfortunately the pexpect-windows-portability issue would leave us no choice but:
To do some serious refactoring on our test libraries to be able to use both winpexpect (or wexpect) and pexpect depending on the os settings.
Or to use cygwin. Guess what, with this second option we seem to have an issue :-) Using Python 2.7.5 on Cygwin64 installing the requests package results in error:
pip says it can not find a file after downloading and extracting the library
easy install doesn't throw an explicit error, but leaves everything in the temporary dir
after copying the files under the site-packages directory a simple import requests in python causes the interpreter to exit
Has anybody encountered this problem? With Cygwin-32 requests install smoothly. (however we have some other issues - see my next post ;-))
Thank you in advance: Joe, the public
Also ran into the same issues when trying to install requests, all the options on http://docs.python-requests.org/en/latest/user/install/#install did not work. I went to https://github.com/kennethreitz/requests and then clicked on "Download Zip" and I got requests-master.zip.
Update: This should be fixed in Cygwin.
This was a bug in CPython that has been fixed in their master branch. I've pushed a candidate package to the Python maintainer for Cygwin, but you might try this hotfix.
I downloaded from "https://github.com/requests/requests" and then i just ran the setup.py from the requests-master folder ( this was placed in cygwin folder). After that I went to cygwin terminal and then I ran python --> import requests. Voila it worked.

ReviewBoard on Windows throwing error 207 when trying to create a review

I am trying in Mercurial with the hgreviewboard extension, to create a working review, like this:
C:\dev\test>hg postreview tip
Changeset 2:938259978c8e
---------------------------
A sample change to be code reviewed.
reviewboard: http://myreviewboard.mysite.com:8081/reviewboard
username: warren
password: **********
Looking for 'myreviewboard.mysite.com /reviewboard/' cookie in C:\Users\userid\A
ppData\Roaming\.post-review-cookies.txt
Loaded valid cookie -- no login required
abort: The file was not found in the repository (207)
stat: fail
file: test.txt
revision: 66bd323b0a11
Similar to this issue I am trying to use ReviewBoard 1.7.9 which I installed using the Bitnami installer, on Windows. I am trying to use it with mercurial. The first challege is that the bitnami install doesn't include the mercurial site-package files in its installation, so once that's remedied, I get stuck where dozens of others seem to get stuck, and I am wondering if my problem is one of the problems that has lead ReviewBoard devs to state that they don't recommend or support running ReviewBoard version 1.7 on Windows.
It seems that whoever packages the upstream bitnami stacks doesn't agree, and has kept right on packaging Bitnami ReviewBoard version 1.7.x versions.
Has anyone got ReviewBoard 1.7.9 working on Windows, with mercurial? Note that above I'm showing you a command line prompt in Windows, but the server-side is also running on Windows, thanks to Bitnami installers for Windows.
It turns out that DNS or getaddrinfo calls were failing to resolve myreviewboard.mysite.com
It really helps to enable the logging features in Reviewboard and set their output to Debug level of verbosity, when Reviewboard is doing something wonky.
At another question here on Stackoverflow, it was recommended that ReviewBoard may not be able to read certain mercurial repository versions and that a clean clone (hg clone -U oldrepo newrepo) is required in order to get it to work in ReviewBoard. I'm including that tip here in case it's not some other thing.
But basically without the debug logs on the server side, a client-side error # 207 is impossible to debug.

BitNami DjangoStack not 'self contained', cannot run application

I installed the Windows (32bit) BitNami DjangoStack 1.4.1.0 and elected not to install the python that came with it as I already have Python 2.7 installed.
I got the error below and also an internal server error when I clicked on the button in the introduction web page (so Appache is running ok)
enter code here
[error] mod_wsgi (pid=3990): Target WSGI script '/opt/bitnami/apps/django/scripts/django.wsgi' cannot be loaded as Python module
I found a similar question but that related to installing on Amazon. Also following through the answers it appeared that the problem is that the wsgi had been compiled against the wrong python version.
I then uninstalled BitNami and re-installed using the python version that was provided - still the same message.
I don't see how the wrong python version can be the problem if the BitNami package is self contained, i.e. comes with all the bits needed to run.
In case my previously installed version was causing the problem I remove it from the PATH environment variable.
Also the documentation for Windows seems wrong. django.conf and django.wsgi are not where the docs say they are (\Users\user\BitNami SDjangoStack projects\apps). In fact the only thing in that directory is the new project I selected on installation - no apps directory. I found the files in the BitNami directories.
Also when I typed python in the BitNami console I got python 2.7.3, not 2.7.2 which is listed in the installation guide.
I thought this package would be wonderful to help me get a production Django site running. It is now ready in the development phase to go live for testing.
What do you exactly mean with not installing Python? BitNami DjangoStack is self contained in the sense that it includes its own Python and its dependecies. Also you mentioned that you are running it on Windows but the path /opt/bitnami is the default path when installing as root in Linux. What exact options did you select during the installation?

Categories

Resources