I have a situation where if I run Apache with wsgi (now uninstalled), a test website works, but running the same server with runserver 0.0.0.0:8080 gives ERR_CONNECTION_REFUSED from local or remote (even with the apache2 service stopped).
Edit: I don't think it's Apache, I've reproduced the problem on a clean server with no Apache installed, so unless Apache somehow modified something under source control it's not that
My knowledge of web details is hazy, I don't even know where to troubleshoot this problem - the devserver runs (runserver prints as expected and doesn't give any errors) but never receives a request, I have nothing in iptables.
Sorry for anyone who read this, it would probably have been impossible to solve given my supplied information.
What had actually happened was that I'd been having to modify my wsgi.py script in order to make it happy inside the Apache server, and I'd added a line which said "os.system('/bin/bash --rcfile )" to try and make sure that when running inside apache it got the virtualenv activated.
This line must have been causing some strange problem, another symptom was that I realised when I was running "runserver", it wasn't crashing the the python process was backgrounding itself, where normally it runs inside that console window.
Thanks everyone who asked questions helping me debug!
Related
I have developed a Python web server using Flask, and some of the endpoints make use of the subprocess module to call different executables. On development, using the Flask debug server, everything works fine. However, when running the server along with nginx+WSGI (on the exact same machine), some subprocess calls fail.
For example, one of the tools I'm using is Microsoft's dotnet, which I installed from my user as sudo apt-get install -y aspnetcore-runtime-5.0 and is then called from Python with the subprocess module. When I run the server with python3 server.py, it works like a charm. However, when using nginx and WSGI, the subprocess call fails with an exception that says: /bin/sh: 1: dotnet: not found.
I suspect this is due to the command not being accessible to the user and group running the server. I have used this guide as a reference to deploy the app, and on the wsgi .ini file, I have set uid = javierd and gid = www-data, while on the systemd .service file I have User=javierd, Group=www-data.
I have tried to add the executables' paths to /etc/profile, but it didn't work, and I don't know any other way to fix it. I find also very surprising that this happens to some executables, but not to all, and that it happes to dotnet, for example, which is located at /usr/bin/dotnet and therefore should be accessible to every user. Any idea on how to solve this problem? Furthermore, if somebody could explain me why this is happening, I would really appreciate the effort.
Thanks a lot!
Ok, finally after having a big headache, I noticed the error, and it was really simple.
On the tutorial I linked, when creating the system service file, the following line was included: Environment="PATH=/home/myuser/myfolder/enviroment/bin".
Of course, as this was overriding the path, there was no way of executing the commands. Once I notices it I just removed that line, restarted the service, and it was fixed.
I added my applications on DigitalOcean. But when I turn on my website I see the error. "502 Bad Gateway nginx/1.14.0 (Ubuntu)". I would like to solve it, but I do not know where I can find logs with errors.
I always used CMD and when I tried to turn on the server, if something did not work, the CMD clearly said what was wrong. Where can I find something like this on DigitalOcean. I used PythonAnywhere once, and there was a separate tab with information about errors (practically the same as in CMS). Please forgive me for simple questions, I have little experience in servers and GIT.
502 probably means you got some errors in your application - you'd better check out your gunicorn(or other WSGI server) logs. Location of the logs depends on what WSGI server you're using but probably you can check it out in WSGI's config file.
Also you can try to do standard 'runserver' just to ensure that your application can run correctly.
ps aux | grep gunicorn (or smth like this command) can tell you if it's runnning.
If it's not, chek out the logs. Also, you can go to your config file, check the command that you're trying to use to start the server, try it out in the console.
In final you can ensure that your nginx config is correct too with nginx -t command.
We are building a school information system using Python/Django. The production server runs Ubuntu, Apache2 with mod_wsgi. Recently strange things happen to our server. When we test our code locally everything works well. After deployment the application works, but sometimes returns 'Page not found' or 'Division by zero' errors. Why is this happen, from attack or server configuration, please help us!
Is server running out of memory or disk errors? Do dmesg, and verify for any exceptions or errors reported.
System is compromised? check for /var/log/auth.log
Secure SSH using non standard port or by installing DenyHosts
Scan through syslog for any other error
If any logging is enabled in django, check for errors.
Apache logs in /var/log/apache2 can give details of access details and any errors.
If none of above, please provide more details like configurations/logs from Apache, Syslog.
I have a python application (webservice) hosted in Openshift but, a few days ago, the app don't work anymore. The log points to "[error] script timed out before returning headers" and I can't solve this.
Someone can help me?
The solution was remove the cartridge and install Python 2.6
Please log in to your openshift account and check whether your application and cartridges are up and running.
From the mod_wsgi FAQ:
Q: Why am I seeing the error message 'premature end of script headers'
in the Apache error logs.
A: If using daemon mode, this is a symptom of the mod_wsgi daemon
process crashing when handling a request. You would probably also see
the message 'segmentation fault'. See answer for question about
'segmentation fault' above.
This error message can also occur where you haven't configured Apache
correctly and your WSGI script file is being executed as a CGI script
instead.
It could also be possibly due to the application code hanging. This can be due to the use of third party Python modules which have a C extension component which does not work in Python sub interpreters.
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API
Unfortunately OpenShift has a less than ideal mod_wsgi configuration and no ready ability to override the configuration nor the start up of Apache itself. At least not unless that have made significant changes since the last time I looked.
I was tasked with making some changes to a Django application. I've never worked with Django and I am having trouble figuring out how to get my changes to compile and be available online.
What I know so far is that the application is currently available online. netstat tells me that httpd is listening on port 80. My change was made in the myapp/views.py file.
I tried to restart httpd using services httpd restart but my changes did not take effect. I've been looking into the issue a bit an I believe that I need to run a command along the lines of:
I tried calling python manage.py runserver MY.IP.AD.DR:8000 and I get:
python manage.py runserver 129.64.101.14:8000
Validating models...
0 errors found
Django version 1.4.1, using settings 'cutsheets.settings'
Development server is running at http://MY.IP.AD.DR:8000/
Quit the server with CONTROL-C.
Nice that no errors are found but when I navigate to http://MY.IP.AD.DR:8000/ I just get a "Unable to connect" message from my browser. I tried with port 81 too and had the same problem.
Without knowing exactly how your application is set up, I can't really say exactly how to solve this problem.
I can tell you that it's quite common to use two web servers with Django - one handles the static content, and reverse proxies everything else to a different port where the Django app is listening. Restarting the normal HTTP daemon therefore wouldn't affect the Django app, so you need to restart the one handling the Django app. Until you restart it, the prior version of the code will be running.
I generally use Nginx as my static server and Gunicorn with the Django app, with Supervisor used to run Gunicorn, and this is a common setup. I recommend you take a look at the config for the main web server to see if it forwards anything to another port. If so, you need to see what server is running on that port and restart it.
Also, is there a Fabric configuration (fabfile.py)? A lot of people use Fabric to automate Django deployments, and if there is one then there may be a command already defined for deploying.