I've setup a python3.9 django project with uWSGI 2.0.12. It seems that every few seconds or so the service crashes and restarts due to some bug in python related to the random seed and a KeyboardInterrupt.
Does anyone have any idea what is going on here? In general the app works, but every so often its not responsive.
The following log lines repeat themselves over and over again.
*** Starting uWSGI 2.0.18 (64bit) on [Sat Jul 30 00:25:13 2022] ***
compiled with version: 11.2.1 20210728 (Red Hat 11.2.1-2) on 27 January 2021 00:00:00
os: Linux-5.14.0-80.el9.x86_64 #1 SMP PREEMPT Thu Apr 21 09:50:22 UTC 2022
nodename: abc.dev
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 2
current working directory: /etc/uwsgi.d
detected binary path: /usr/sbin/uwsgi
chdir() to /opt/abc-api/mysite
your processes number limit is 15518
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /var/sockets/api.abc.dev.sock fd 6
Python version: 3.9.13 (main, Jun 9 2022, 00:00:00) [GCC 11.3.1 20220421 (Red Hat 11.3.1-2)]
PEP 405 virtualenv detected: /opt/abc-api/venv
Set PythonHome to /opt/abc-api/venv
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0xb32450
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 145840 bytes (142 KB) for 1 cores
*** Operational MODE: single process ***
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0xb32450 pid: 219059 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 219059)
spawned uWSGI worker 1 (pid: 219060, cores: 1)
Sat Jul 30 00:25:13 2022 - received message 0 from emperor
SIGINT/SIGQUIT received...killing workers...
Traceback (most recent call last):
File "/usr/lib64/python3.9/random.py", line 126, in seed
def seed(self, a=None, version=2):
KeyboardInterrupt
Update:
I've tried many things - including going back python3.7 (couldn't get it to work, different issue...). Finally I went back to 3.9 setup, but instead of using a socket file, I decided on http socket at 127.0.0.1:8181. Now this issue is not happening. Zero clue what's going on, but looks like it has to do with the socket file.
Related
I am trying to run one sample application with uWSGI file directive using two files for it testService.ini(config file) & testService.py (application file).
**testService.ini**
[uwsgi]
wsgi-file = '/opt/testService/testService.py'
callable = app
**testService.py**
def application(env, start_response):
start_response('200 OK', [('Content-Type','text/html')])
return [b"Hello World"]
running the above file using : uwsgi --http :9090 --wsgi-file testService.ini
Output:
Starting uWSGI 2.0.17 (64bit) on [Thu Jun 21 15:52:33 2018]
compiled with version: 5.4.0 20160609 on 14 June 2018 10:09:32
os: Linux-4.13.0-45-generic #50~16.04.1-Ubuntu SMP Wed May 30 11:18:27 UTC 2018
nodename: ubuntu
machine: x86_64
clock source: unix
detected number of CPU cores: 8
current working directory: /opt/testService
detected binary path: /home/jmallick/.local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 15481
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uWSGI http bound on :9090 fd 4
spawned uWSGI http 1 (pid: 7848)
uwsgi socket 0 bound to TCP address 127.0.0.1:45781 (port auto-assigned) fd 3
Python version: 2.7.12 (default, Dec 4 2017, 14:50:18) [GCC 5.4.0 20160609]
Python threads support is disabled. You can enable it with --enable-threads
Python main interpreter initialized at 0x824400
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 72920 bytes (71 KB) for 1 cores
Operational MODE: single process
File "testService.ini", line 2
**wsgi-file = '/opt/testService/testService.py'
SyntaxError: can't assign to operator
failed to compile python file testService.ini**
unable to load app 0 (mountpoint='') (callable not found or import error)
no app loaded. going in full dynamic mode
uWSGI is running in multiple interpreter mode
spawned uWSGI worker 1 (and the only) (pid: 7847, cores: 1)
And over the browser I am getting "Internal Server Error". Can someone help me understanding what I am doing wrong here ?
I have an issue testing my flask API app where it won't consistently start up. Because of requirements, I have to make sure it runs on CentOS6 (python 2.6 by default), but I use a custom python 2.7 virtualenv. My startup command is as follows:
/opt/mist/mist_base/env/bin/uwsgi --py-autoreload 1 --master --socket=/tmp/mist_app.sock --pidfile=/tmp/mist_app.pid --module=wsgi --honour-stdin --chdir=/opt/mist/mist_base/app --threads=1 --virtualenv=/opt/mist/mist_base/env --die-on-term --uid mist --gid mist
where the custom virtualenv is /opt/mist/mist_base/env.
I had someone help me package this software to be installable using RPM/Yum (he had done it before and packaging it this way was a requirement); during this process he insisted that he build another custom python virtualenv (/opt/mist/mist_base/.localpython). Unfortunately he has since left the company, and we don't have details as to what was done. I looked for RPM build/init commands that would call binaries/libraries in that other virtualenv but I didn't find any.
Using the instructions provided to me, I built the resulting RPM and installed it on my test server and everything runs just fine. I gave the same RPM to my customer to install in his test server and it does not start.
My working boot sequence is as follows:
*** Starting uWSGI 2.0.14 (64bit) on [Thu May 18 13:49:09 2017] ***
compiled with version: 4.4.7 20120313 (Red Hat 4.4.7-17) on 20 March 2017 07:18:55
os: Linux-2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Apr 11 17:13:24 UTC 2017
nodename: mistdb
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 4
current working directory: /opt/mist/mist_base/app
writing pidfile to /tmp/mist_app.pid
detected binary path: /opt/mist/mist_base/env/bin/uwsgi
setgid() to 487
setuid() to 493
chdir() to /opt/mist/mist_base/app
your processes number limit is 7394
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /tmp/mist_app.sock fd 3
Python version: 2.7.5 (default, Mar 20 2017, 06:43:30) [GCC 4.4.7 20120313 (Red Hat 4.4.7-17)]
Set PythonHome to /opt/mist/mist_base/env
Python main interpreter initialized at 0x21c4aa0
python threads support enabled
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 145536 bytes (142 KB) for 1 cores
*** Operational MODE: single process ***
WSGI app 0 (mountpoint='') ready in 2 seconds on interpreter 0x21c4aa0 pid: 24902 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 24902)
spawned uWSGI worker 1 (pid: 24907, cores: 1)
Python auto-reloader enabled
Meanwhile this is what my customer sees:
*** Starting uWSGI 2.0.14 (64bit) on [Tue May 16 13:12:26 2017] ***
compiled with version: 4.4.7 20120313 (Red Hat 4.4.7-17) on 20 March 2017 07:18:55
os: Linux-2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017
nodename: mist-testbed
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 2
current working directory: /
writing pidfile to /tmp/mist_app.pid
detected binary path: /opt/mist/mist_base/env/bin/uwsgi
setgid() to 497
setuid() to 497
chdir() to /opt/mist/mist_base/app
your processes number limit is 15208
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /tmp/mist_app.sock fd 3
Python version: 2.7.5 (default, Mar 20 2017, 06:43:30) [GCC 4.4.7 20120313 (Red Hat 4.4.7-17)]
Set PythonHome to /opt/mist/mist_base/env
Python main interpreter initialized at 0x280c890
python threads support enabled
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 145536 bytes (142 KB) for 1 cores
*** Operational MODE: single process ***
ERROR:root:code for hash md5 was not found.
Traceback (most recent call last):
File "/opt/mist/mist_base/.localpython/lib/python2.7/hashlib.py", line 139, in <module>
globals()[__func_name] = __get_hash(__func_name)
File "/opt/mist/mist_base/.localpython/lib/python2.7/hashlib.py", line 103, in __get_openssl_constructor
return __get_builtin_constructor(name)
File "/opt/mist/mist_base/.localpython/lib/python2.7/hashlib.py", line 91, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5
Traceback (most recent call last):
File "./wsgi.py", line 1, in <module>
from mist_main import app as application
File "./mist_main.py", line 1, in <module>
from _app import return_app
File "./_app.py", line 1, in <module>
from flask import Flask, Blueprint, render_template, session, redirect, url_for, escape, request, abort
File "/opt/mist/mist_base/env/lib/python2.7/site-packages/flask/__init__.py", line 17, in <module>
from werkzeug.exceptions import abort
File "/opt/mist/mist_base/env/lib/python2.7/site-packages/werkzeug/__init__.py", line 151, in <module>
__import__('werkzeug.exceptions')
File "/opt/mist/mist_base/env/lib/python2.7/site-packages/werkzeug/exceptions.py", line 71, in <module>
from werkzeug.wrappers import Response
File "/opt/mist/mist_base/env/lib/python2.7/site-packages/werkzeug/wrappers.py", line 26, in <module>
from werkzeug.http import HTTP_STATUS_CODES, \
File "/opt/mist/mist_base/env/lib/python2.7/site-packages/werkzeug/http.py", line 32, in <module>
from hashlib import md5
ImportError: cannot import name md5
unable to load app 0 (mountpoint='') (callable not found or import error)
*** no app loaded. going in full dynamic mode ***
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 25071)
spawned uWSGI worker 1 (pid: 25072, cores: 1)
Python auto-reloader enabled
During startup, the app first tries to use the .localpython virtualenv, then it tries using the env virtualenv. Since I can't find any RPM/init code that uses .localpython, I can't explain why 1. my app instance doesn't use it 2. my customer's instance does.
It's entirely possible it's due to a difference in environments, and we're going to try and build a VM based on their specs and see if that resolves this issue. Could this also simply be a case of having a broken virtualenv and/or not having all the needed external libraries not included?
My customer came back today and it looks like they do something additional to their CentOS 6 servers that we don't do. Specifically, they run a script to FIPS-enable their servers and that somehow screws with how my custom python 2.7 environment interacts with the built-in encryption libraries.
The issue here is that everything is configured, and runs without error, and yet I do not know why it is not working. As you'll see I get no app can't load error, I get no errors at all, in fact it's the most complete without errors I've had since I started. And yet, 500 response. Alot of this is here for completeness as I'll explain. If I take emperor out of the mix, it works, just fine.
I have been trying to deploy an opensource flask app ceph-dash for monitoring via uwsgi/nginx. I succeeded eventually albeit painfully. I have written a gist about my success https://gist.github.com/Lighiche/a6aec14166d62b4f8f013415a2c1f757
Howver, since there's no daemon management and the likes I thought it best to add to what I've done by using uwsgi emperor and I followed this guide to the letter
https://chriswarrick.com/blog/2016/02/10/deploying-python-web-apps-with-nginx-and-uwsgi-emperor/
I am on Centos 7. I have successful run and tested the app on this implementation as you can see in the gist, I actually went out of my way to discover how to configure uwsgi under different scenarios.
However with the emperor implementation of wsgi and all it's config files. I am getting a 500 response internal server error. And I think it's to do with the hand off between nginx and emperor or emperor itself. As when I stop the uwsgi service I get a 502. So nginx at least sees the socket file.
WSGI server start log, all green
*** Starting uWSGI 2.0.13.1 (64bit) on [Thu Sep 1 11:16:24 2016] ***
compiled with version: 4.8.5 20150623 (Red Hat 4.8.5-4) on 02 August 2016 21:07:54
os: Linux-3.10.0-327.28.3.el7.x86_64 #1 SMP Thu Aug 18 19:05:49 UTC 2016
nodename: prdceph-mon00
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 2
current working directory: /etc/uwsgi.d
detected binary path: /usr/sbin/uwsgi
chdir() to /etc/nginx/sites-enabled/ceph-dash
your processes number limit is 7282
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /var/run/uwsgi/ceph-dash.sock fd 6
Python version: 2.7.5 (default, Aug 18 2016, 15:58:25) [GCC 4.8.5 20150623 (Red Hat 4.8.5-4)]
Python main interpreter initialized at 0xee1030
python threads support enabled
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 363840 bytes (355 KB) for 4 cores
*** Operational MODE: preforking ***
WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0xee1030 pid: 3236 (default app)
mountpoint already configured. skip.
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 3236)
spawned uWSGI worker 1 (pid: 3241, cores: 1)
spawned uWSGI worker 2 (pid: 3242, cores: 1)
spawned uWSGI worker 3 (pid: 3243, cores: 1)
spawned uWSGI worker 4 (pid: 3244, cores: 1)
[pid: 3243|app: 0|req: 1/1] 127.0.0.1 () {34 vars in 429 bytes} [Thu Sep 1 11:17:31 2016] GET / => generated 291 bytes in 77 msecs (HTTP/1.1 500) 2 headers in 84 bytes (1 switches on core 0)
announcing my loyalty to the Emperor...
WSGI service start log, all green
uwsgi.service - uWSGI Emperor Service
Loaded: loaded (/usr/lib/systemd/system/uwsgi.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2016-09-01 11:16:24 BST; 2s ago
Process: 3231 ExecStartPre=/bin/chown uwsgi:uwsgi /run/uwsgi (code=exited, status=0/SUCCESS)
Process: 3229 ExecStartPre=/bin/mkdir -p /run/uwsgi (code=exited, status=0/SUCCESS)
Main PID: 3234 (uwsgi)
Status: "The Emperor is governing 1 vassals"
CGroup: /system.slice/uwsgi.service
├─3234 /usr/sbin/uwsgi --ini /etc/uwsgi.ini
├─3235 /usr/sbin/uwsgi --ini /etc/uwsgi.ini
├─3236 /usr/sbin/uwsgi --ini cephdash.ini
├─3241 /usr/sbin/uwsgi --ini cephdash.ini
├─3242 /usr/sbin/uwsgi --ini cephdash.ini
├─3243 /usr/sbin/uwsgi --ini cephdash.ini
└─3244 /usr/sbin/uwsgi --ini cephdash.ini
Sep 01 11:16:24 prdceph-mon00 uwsgi[3234]: thunder lock: disabled (you can enable it with --thunder-lock)
Sep 01 11:16:24 prdceph-mon00 uwsgi[3234]: your mercy for graceful operations on workers is 60 seconds
Sep 01 11:16:24 prdceph-mon00 uwsgi[3234]: *** Operational MODE: no-workers ***
Sep 01 11:16:24 prdceph-mon00 uwsgi[3234]: spawned uWSGI master process (pid: 3234)
Sep 01 11:16:24 prdceph-mon00 uwsgi[3234]: *** Stats server enabled on /run/uwsgi/stats.sock fd: 7 ***
Sep 01 11:16:24 prdceph-mon00 uwsgi[3234]: *** starting uWSGI Emperor ***
Sep 01 11:16:24 prdceph-mon00 uwsgi[3234]: *** has_emperor mode detected (fd: 7) ***
Sep 01 11:16:24 prdceph-mon00 uwsgi[3234]: [uWSGI] getting INI configuration from cephdash.ini
Sep 01 11:16:25 prdceph-mon00 uwsgi[3234]: Thu Sep 1 11:16:25 2016 - [emperor] vassal cephdash.ini has been spawned
Sep 01 11:16:25 prdceph-mon00 uwsgi[3234]: Thu Sep 1 11:16:25 2016 - [emperor] vassal cephdash.ini is ready to accept requests
WSGI server response 500
[pid: 3243|app: 0|req: 1/1] 127.0.0.1 () {34 vars in 429 bytes} [Thu Sep 1 11:17:31 2016] GET / => generated 291 bytes in 77 msecs (HTTP/1.1 500) 2 headers in 84 bytes (1 switches on core 0)
NGINX server response 500
<ip> - - [01/Sep/2016:11:14:16 +0100] "GET / HTTP/1.1" 500 291 "http://<ip>/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36" "<my ip>, <ip>"
127.0.0.1 - - [01/Sep/2016:11:17:31 +0100] "GET / HTTP/1.1" 500 291 "-" "Python-urllib/2.7"
cat /etc/uwsgi.ini
[uwsgi]
uid = uwsgi
gid = nginx
pidfile = /run/uwsgi/uwsgi.pid
emperor = /etc/uwsgi.d
stats = /run/uwsgi/stats.sock
#emperor-tyrant = true
cap = setgid,setuid
cat /etc/uwsgi.d/cephdash.ini (this is a symlink to the wsgi.ini for the app)
[uwsgi]
chdir = /etc/nginx/sites-enabled/ceph-dash
wsgi-file = /etc/nginx/sites-enabled/ceph-dash/contrib/wsgi/cephdash.wsgi
module = ceph-dash:app
enable-threads = true
master = true
processes = 4
socket = /var/run/uwsgi/ceph-dash.sock
chmod-socket = 777
vacuum = true
uid = uwsgi
gid = nginx
daemonize = /tmp/ceph-dash.log
plugins = python,logfile
logger = file:/tmp/myappuwsgi.log
cat /etc/nginx/conf.d/cephdash.conf
upstream uwsgi {
server unix:///var/run/uwsgi/ceph-dash.sock;
}
server {
listen 5000;
server_name <hostname>
charset utf-8;
location / {
uwsgi_pass uwsgi;
include /etc/nginx/sites-enabled/ceph-dash/contrib/nginx/uwsgi_params;
}
}
I have uninstalled the uwsgi that I installed via pip. I appear still to have a /sbin/uwsgi (linked from /usr/sbin) which looks to be the one installed for systemd and a /usr/bin/uwsgi I don't know how that happened. I changed the .service file to use /usr/bin and have the same error. However the binary from the rpm does not have the plugsin installed and the one in /usr/bin does. systemd uwsgi now starts with /usr/bin/uwsgi and as you can see below that binary loads the plugins required but I get the same internal server error, and the same messaged from systemd and startup logs no errors, no failures. Just a 500.
rpm -ql uwsgi
/etc/uwsgi.d
/etc/uwsgi.ini
/run/uwsgi
/usr/lib/systemd/system/uwsgi.service
/usr/sbin/uwsgi
/usr/share/doc/uwsgi-2.0.13.1
/usr/share/doc/uwsgi-2.0.13.1/CHANGELOG
/usr/share/doc/uwsgi-2.0.13.1/README
/usr/share/doc/uwsgi-2.0.13.1/README.Fedora
/usr/share/licenses/uwsgi-2.0.13.1
/usr/share/licenses/uwsgi-2.0.13.1/LICENSE
python --version
Python 2.7.5
uwsgi --version
2.0.13.1
which uwsgi (POINTING TO THE RIGHT PLACE but systemd is now loading /usr/bin)
/sbin/uwsgi
uwsgi --plugins-list (DOES NOT SHOW THE PLUGINS LOADED)
*** uWSGI loaded generic plugins ***
corerouter
*** uWSGI loaded request plugins ***
100: ping
101: echo
--- end of plugins list ---
*** Starting uWSGI 2.0.13.1 (64bit) on [Thu Sep 8 09:58:40 2016] ***
compiled with version: 4.8.5 20150623 (Red Hat 4.8.5-4) on 02 August 2016 21:07:54
os: Linux-3.10.0-327.28.3.el7.x86_64 #1 SMP Thu Aug 18 19:05:49 UTC 2016
nodename: prdceph-mon00
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 2
current working directory: /tmp
detected binary path: /usr/sbin/uwsgi
uWSGI running as root, you can use --uid/--gid/--chroot options
*** WARNING: you are running uWSGI as root !!! (use the --uid flag) ***
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 7282
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
The -s/--socket option is missing and stdin is not a socket.
/usr/bin/uwsgi --plugins-list
DOES SHOW THE PLUGINS LOADED
*** uWSGI loaded generic plugins ***
gevent
nagios
rrdtool
carbon
corerouter
fastrouter
http
ugreen
syslog
rsyslog
logsocket
router_uwsgi
router_redirect
router_basicauth
zergpool
redislog
mongodblog
router_rewrite
router_http
logfile
router_cache
rawrouter
router_static
sslrouter
cheaper_busyness
transformation_tofile
transformation_gzip
transformation_chunked
transformation_offload
router_memcached
router_redis
router_hash
router_expires
router_metrics
transformation_template
stats_pusher_socket
*** uWSGI loaded request plugins ***
0: python
17: spooler
18: symcall
100: ping
110: signal
111: cache
173: rpc
--- end of plugins list ---
*** Starting uWSGI 2.0.13.1 (64bit) on [Thu Sep 8 09:58:50 2016] ***
compiled with version: 4.8.5 20150623 (Red Hat 4.8.5-4) on 29 August 2016 09:55:26
os: Linux-3.10.0-327.28.3.el7.x86_64 #1 SMP Thu Aug 18 19:05:49 UTC 2016
nodename: prdceph-mon00
machine: x86_64
clock source: unix
detected number of CPU cores: 2
current working directory: /tmp
detected binary path: /usr/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
uWSGI running as root, you can use --uid/--gid/--chroot options
*** WARNING: you are running uWSGI as root !!! (use the --uid flag) ***
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 7282
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
The -s/--socket option is missing and
uWSGI installed by yum and by pip are different. Systemd will probably use one installed by yum. When you're SSH'ing and running uWSGI by yourself, system will use one installed by pip by default.
Main difference between that uWSGI versions is: lack of python support in one installed by yum, because it tends to be modular. You can install it, probably by using yum install uwsgi-python (check your distribution repositories for specific package name). Be aware that different python plugins are needed for different python versions (2.7 will require different plugin than 3.5) and adjust package name to be installed accordingly.
After installation of python plugin check that's plugin name (visible for uWSGI) and adjust value in plugins in your .ini file. That name will probably match installed package name without uwsgi- prefix.
For me, I tried to restart nginx but it kept giving an error. I found the problem to be an extra .conf file in sitesavailable folder.
I changed my uWSGI setup to use the Emperor for multi-app deployment. With the old setup when loading 'mypasswords.pwds' file which was saved right next to my app, there was no issue.
Now running everything with the Emperor I get 'No such file or direcotry' errors. This might be because of my setup or because the Emperor simply works in a different way and I'm not sure what's the case.
Directory Tree:
Project
thisismyapp.py
passwords.pwds
Config for uWSGI Emperor:
[uwsgi]
# Variables
base = /var/www/Project
# Generic Config
home = %(base)/venv
pythonpath = %(base)
socket = /tmp/%n.sock
module = thisismyapp:app # Is this an issue?
logto = /var/log/uwsgi/%n.log
Traceback:
*** Starting uWSGI 2.0.11.2 (64bit) on [Thu Feb 4 00:41:47 2016] ***
compiled with version: 4.9.2 on 24 October 2015 23:42:32
os: Linux-3.19.0-42-generic #48-Ubuntu SMP Thu Dec 17 22:54:45 UTC 2015
nodename: website
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /etc/uwsgi/apps-enabled
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
your processes number limit is 1868
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /tmp/project.sock fd 3
Python version: 2.7.9 (default, Apr 2 2015, 15:37:21) [GCC 4.9.2]
Set PythonHome to /var/www/Project/venv
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x17355e0
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 145520 bytes (142 KB) for 1 cores
*** Operational MODE: single process ***
added /var/www/Project/ to pythonpath.
WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0x17355e0 pid: 6772 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 6772)
spawned uWSGI worker 1 (pid: 6779, cores: 1)
[pid: 6779|app: 0|req: 1/1] 79.227.145.119 () {46 vars in 967 bytes} [Thu Feb 4 00:41:51 2016] GET / => generated 3552 bytes in 355 msecs (HTTP/1.1 200) 2 headers in 81 bytes (1 switches on core 0)
announcing my loyalty to the Emperor...
[Errno 2] No such file or directory: 'passwords.pwds'
Python file access:
f = open('passwords.pwds', 'r')
Try this one:
from os import path
passwords_location = path.join(path.dirname(path.realpath(__file__), 'passwords.pwds'))
with open(passwords_location) as f:
do_something()
Your original way using the relative location, so may can't find the file if you're not in the Project folder. Also, use with block is a better way to handle files, it will ensure to close the file when exit the context block.
I've tried some uwsgi tutorials but can't get a simple python script to run in my browser.
Ive read through this (http://uwsgi-docs.readthedocs.org/en/latest/WSGIquickstart.html) and this (https://www.digitalocean.com/community/articles/how-to-deploy-python-wsgi-applications-using-uwsgi-web-server-with-nginx) and others, but for some reason can't get a simple uwsgi app running. I am currently not going through a web server, just uwsgi by itself.
I have the following wsgi.py:
def application(env, start_response):
start_response('200 OK', [('Content-Type', 'text/html')])
return ["Hello!"]
and I run:
uwsgi --socket 127.0.0.1:8080 --chdir /my/program/path --pp .. -w wsgi
which produces the following output (looks promising):
*** Starting uWSGI 2.0.3 (64bit) on [Mon Apr 14 12:51:32 2014] ***
compiled with version: 4.6.3 20120306 (Red Hat 4.6.3-2) on 14 April 2014 12:01:33
os: Linux-3.1.0-7.fc16.x86_64 #1 SMP Tue Nov 1 21:10:48 UTC 2011
nodename: ip-10-252-98-215
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /usr/oai/icscada/www
detected binary path: /usr/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
uWSGI running as root, you can use --uid/--gid/--chroot options
*** WARNING: you are running uWSGI as root !!! (use the --uid flag) ***
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 1024
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to TCP address 127.0.0.1:8080 fd 3
Python version: 2.7.3 (default, Jul 24 2012, 11:41:40) [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x2504ee0
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 72752 bytes (71 KB) for 1 cores
*** Operational MODE: single process ***
added ../ to pythonpath.
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x2504ee0 pid: 21702 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (and the only) (pid: 21702, cores: 1)
but when I go to port 8080 from my browser I get a "could not connect" error. Port 8080 is open and has been tested.
I've also tried the following wsgi.py:
import os
os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
exactly the same results
If you want to run uWSGI without a web server in front of it, use http option instead of socket. See Native HTTP support.
Also, use 0.0.0.0:80 as an address if you are accessing from a remote machine.