I'm having a problem which is driving me nuts. I'm trying to create an Ubuntu 15.04 Upstart job, which would start uWSGI server (uWSGI version 2.0.7-debian) running a Django application.
I've configured the service as a follows and try to start the job by issuing command $ sudo service uwsgi start. There is no output in log files, no socket file created and no error.
# file: /etc/init/uwsgi.conf
description "uWSGI server"
start on runlevel [2345]
stop on runlevel [!2345]
exec /usr/bin/uwsgi --ini /srv/configs/uwsgi.ini
service uwsgi status says
● uwsgi.service - LSB: Start/stop uWSGI server instance(s)
Loaded: loaded (/etc/init.d/uwsgi)
Active: active (exited) since Tue 2015-05-05 09:40:08 EEST; 1s ago
Docs: man:systemd-sysv-generator(8)
Process: 21405 ExecStop=/etc/init.d/uwsgi stop (code=exited, status=0/SUCCESS)
Process: 21460 ExecStart=/etc/init.d/uwsgi start (code=exited, status=0/SUCCESS)
May 05 09:40:08 web-2 systemd[1]: Starting LSB: Start/stop uWSGI server instance(s)...
May 05 09:40:08 web-2 uwsgi[21460]: * Starting app server(s) uwsgi
May 05 09:40:08 web-2 uwsgi[21460]: ...done.
May 05 09:40:08 web-2 systemd[1]: Started LSB: Start/stop uWSGI server instance(s).
The uWSGI app is configured as
[uwsgi]
uid = www-data
gid = www-data
socket = /srv/sockets/uwsgi.sock
chmod-socket = 666
master = true
processes = 4
enable-threads = true
plugins = python
chdir = /srv/sites/current
module = wsgi:application
virtualenv = /srv/environments/current
logto = /srv/logs/uwsgi.log
logfile-chown = true
touch-reload = /srv/sites/current/wsgi.py
The service starts fine and everything works ok if the service is started directly, e.g. by issuing command:
sudo -u www-data /usr/bin/uwsgi --ini /srv/configs/uwsgi.ini
For the socket dir and log files directories I've set the most relaxed permissions.
So, I'm at a loss. What to do next?
Thanks to nmgeeks comment, I started looking at other places where uWSGI is configured.
While trying to move everything our own app related under /srv I deleted /run/uwsgi directory, where uWSGI is trying to create a PID file.
You can find the reference at /usr/share/uwsgi/conf/default.ini.
Too bad uWSGI doesn't produce any error in this situation, which left me frustrated for a day.
I just want to put some additional details. In my case I didn't delete anything, but, for some reasons, systemd was not able to create /run/uwsgi directory. So, I did echo "/run/uwsgi 0755 www-data www-data -" > /etc/tmpfiles.d/uwsgi.conf. After that I restarted my VM (I didn't find a way to apply this changes without restarting) and uwsgi started to work!
Yes, it's too bad that uWSGI doesn't produce any error in this situation.
Related
I have a nginx server setup with django and uwsgi.
There are multiple django apps run simultaneously on different virualenvs, separate uwsgi processes on separate ports on which nginx listens to.
The setup works alright.
I use pidfile flag to stop uwsgi processes. When I start the any uwsgi server, pidfile is created and I can immediately restart without errors with the script provided below.
After while when I come back to update the server, the pidfile is gone and the uwsgi process is still running. This makes this approach useless.
project_A_uwsgi.ini:
[uwsgi]
master = true
socket = /tmp/stripe_test_uwsgi.sock
chmod-socket = 666
chdir = /home/ubuntu/TestProjects/ProjectA
wsgi-file = /home/ubuntu/TestProjects/ProjectA/ProjectA/wsgi.py
virtualenv = /home/ubuntu/TestProjects/ProjectA/venv
vacuum = true
enable-threads = true
daemonize= /home/ubuntu/TestProjects/ProjectA/uwsgi.log
project_A_server_restart.sh:
#!/bin/sh
DEPLOYMENT_PATH='/home/ubuntu/TestProjects/ProjectA'
. ${DEPLOYMENT_PATH}/venv/bin/activate
uwsgi --stop /home/ubuntu/TestProjects/project_A_uwsgi.pid
uwsgi --ini /home/ubuntu/TestProjects/project_A_uwsgi.ini --pidfile /home/ubuntu/TestProjects/project_A_uwsgi.pid
sudo service nginx restart
What could be the reason for the pidfile to get deleted? how will I prevent that?
Glusterfs-server can't stop in good status.
I have been trying the following steps to install glusterfs and start service.
yum install centos-release-gluster
yum install glusterfs-server
systemctl start glusterd
and stop it.
systemctl stop glusterd
Then displayed following status "Active: failed".
glusterd.service - GlusterFS, a clustered file-system server
Loaded: loaded (/usr/lib/systemd/system/glusterd.service; disabled)
Active: failed (Result: exit-code) since 火 2017-01-24 18:23:55 JST; 4s ago
Process: 2523 ExecStart=/usr/sbin/glusterd -p /var/run/glusterd.pid --log-level $LOG_LEVEL $GLUSTERD_OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 2524 (code=exited, status=15)
1月 24 18:23:52 ds009 systemd[1]: Started GlusterFS, a clustered file-system server.
1月 24 18:23:55 ds009 systemd[1]: Stopping GlusterFS, a clustered file-system server...
1月 24 18:23:55 ds009 systemd[1]: glusterd.service: main process exited, code=exited, status=15/n/a
1月 24 18:23:55 ds009 systemd[1]: Stopped GlusterFS, a clustered file-system server.
1月 24 18:23:55 ds009 systemd[1]: Unit glusterd.service entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.
Using environment is"CentOS Linux release 7.2.1511 (Core)"
And installed glusterfs-server version is 3.8.8-1.el7.
Does anyone have an idea what wrong is and to fix this.
I have found a workaround.
Edit /usr/lib/systemd/system/glusterd.service file as following.
[Service]
Type=forking
PIDFile=/var/run/glusterd.pid
LimitNOFILE=65536
Environment="LOG_LEVEL=INFO"
EnvironmentFile=-/etc/sysconfig/glusterd
ExecStart=/usr/sbin/glusterd -p /var/run/glusterd.pid --log-level $LOG_LEVEL $GLUSTERD_OPTIONS
ExecStopPost=/usr/bin/systemctl reset-failed glusterd # Add this
KillMode=process
The failed status is clear when the GlusterFS service stop.
I am trying to set up uwsgi.service to run on systemd for Django 1.10 on Linode with Fedora 24.
/etc/systemd/system/uwsgi.service
[Unit]
Description=uWSGI Emperor
After=syslog.target
[Service]
ExecStart=/home/ofey/djangoenv/bin/uwsgi --ini /etc/uwsgi/emperor.ini
Restart=always
KillSignal=SIGQUIT
Type=notify
StandardError=syslog
NotifyAccess=all
[Install]
WantedBy=multi-user.target
This should then call,
/etc/uwsgi/emporer.ini
[uwsgi]
emperor = /etc/uwsgi/vassals
uid = www-data
gid = www-data
limit-as = 1024
logto = /tmp/uwsgi.log
I then use a symbolic link,
$ sudo ln -s /home/ofey/djangoForum/django.ini /etc/uwsgi/vassals/
to
/home/ofey/djangoForum/django.ini
[uwsgi]
project = djangoForum
base = /home/ofey
chdir = %(base)/%(project)
home = %(base)/djangoenv
module = crudProject.wsgi:application
master = true
processes = 2
socket = 127.0.0.1:3031
chmod-socket = 664
vacuum = true
I have restarted all with,
$ sudo systemctl daemon-reload
$ sudo systemctl restart nginx.service
$ sudo systemctl retart uwsgi.service
The last command gives,
Job for uwsgi.service failed because the control process exited with error code. See "systemctl status uwsgi.service" and "journalctl -xe" for details.
$ sudo systemctl status uwsgi.service
gives,
● uwsgi.service - uWSGI Emperor
Loaded: loaded (/etc/systemd/system/uwsgi.service; disabled; vendor preset: disabled)
Active: inactive (dead)
Dec 07 23:56:28 ofeyspi systemd[1]: Starting uWSGI Emperor...
Dec 07 23:56:28 ofeyspi uwsgi[7834]: [uWSGI] getting INI configuration from /etc/uwsgi/emperor.ini
Dec 07 23:56:28 ofeyspi systemd[1]: uwsgi.service: Main process exited, code=exited, status=1/FAILURE
Dec 07 23:56:28 ofeyspi systemd[1]: Failed to start uWSGI Emperor.
Dec 07 23:56:28 ofeyspi systemd[1]: uwsgi.service: Unit entered failed state.
Dec 07 23:56:28 ofeyspi systemd[1]: uwsgi.service: Failed with result 'exit-code'.
Dec 07 23:56:28 ofeyspi systemd[1]: uwsgi.service: Service hold-off time over, scheduling restart.
Dec 07 23:56:28 ofeyspi systemd[1]: Stopped uWSGI Emperor.
Dec 07 23:56:28 ofeyspi systemd[1]: uwsgi.service: Start request repeated too quickly.
Dec 07 23:56:28 ofeyspi systemd[1]: Failed to start uWSGI Emperor.
I can not figure out why uwsgi.service will not run.
uwsgi runs when I don't go through systemd and instead use,
$ sudo --ini django.ini
The most likely reason for that is that Emperor is not able to:
create the .pid file to write the processID;
create the unix-socket files for the vassals (seems to be not your case, since you are using :3031 port);
write to the log file specified by --logto option (/tmp/uwsgi.log in your case).
This often happens when any of these files exist and are owned by another user (most likely, root) or are located in a directory to which the user starting the service is not able to write.
Systemd's status log is not very informative on this subject. So, the quickest way to identify the case is to run your ExecStart command from systemd's service not as root and to see the output:
$ /home/ofey/djangoenv/bin/uwsgi --ini /etc/uwsgi/emperor.ini
If the output shows that the problem is permission, try the following.
Since you are going to run your server on behalf of www-data user, as it has been suggested already, make sure you have:
[Service]
User=www-data
Group=www-data
RuntimeDirectory=uwsgi
in your systemd unit config. Then, make sure the .pid files and unix-socket files (if any) are created under that directory (i.e. under /run/uwsgi) by adding this to your vassals .ini files:
runtime_dir = /run/uwsgi
pidfile=%(runtime_dir)/%n.pid
# if you prefer using unix-socket instead of a port
socket = %(runtime_dir)/%n.sock
# trying to chmod-socket is useless with a port, by the way
chmod-socket = 664
The %n variable in the given example stands for the vassal's .ini file name without extension (see the full-list here).
Finally, make sure the --logto file specified in Emperor's and vassals' configs is writable by such.
Please note, if you run uwsgi --ini /etc/uwsgi/emperor.ini as root and then terminate the procecc with ctrl+D, it will leave the above-mentioned temp files existing and owned by root, which will prevent other owners (like www-data) from writing to them, until you delete the files or chown/chmod them again.
The uwsgi systemd docs advise adding RuntimeDirectory=uwsgi to your service file. Try adding that.
Also check /tmp/uwsgi.log to see if any logging was generated there.
Comment out KillSignal = SIGQUIT
It can cause problems, see http://uwsgi-docs.readthedocs.io/en/latest/Systemd.html
also causes issues on Centos 7
I'm trying to deploy my Flask app using uWSGI, but I can't seem to do it without sudo.
Here is my start script:
#!/bin/bash
set -v
set -e
cd /var/hpit/hpit_services
/var/hpit/hpit_services/env/bin/uwsgi --http [::]:80 --master --module wsgi --callable app --processes 4 --daemonize ../log/uwsgi.log --pidfile ../server_pid_file.pid
echo server started
Here is what I get in the logs:
*** Starting uWSGI 2.0.9 (64bit) on [Mon Jan 26 15:53:26 2015] ***
compiled with version: 4.8.2 on 23 January 2015 20:35:44
os: Linux-3.18.1-x86_64-linode50 #1 SMP Tue Jan 6 12:14:10 EST 2015
nodename: <<blocked out>>
machine: x86_64
clock source: unix
detected number of CPU cores: 2
current working directory: /var/hpit/hpit_services
writing pidfile to ../server_pid_file.pid
detected binary path: /var/hpit/hpit_services/env/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
your processes number limit is 7962
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)
bind(): Permission denied [core/socket.c line 764]
Core/socket.c line 764 has this:
if (bind(serverfd, (struct sockaddr *) &uws_addr, addr_len) != 0) {
if (errno == EADDRINUSE) {
uwsgi_log("probably another instance of uWSGI is running on the same address (%s).\n", socket_name);
}
uwsgi_error("bind()");
uwsgi_nuclear_blast();
return -1;
}
But I don't have instances of uWSGI running. This seems to be a permissions issue. My permissions for /var/hpit, /var/hpit/hpit_services (the location of the app) and /var/hpit/log are bsauer:www-data. My user us bsauer.
If I append sudo -E to the line in my start script that calls the uWSGI binary, it seems to start fine, but I read that a server should not be started as sudo. I inherited this sysadmin role at work and am a little new to all of this.
Here are my hunches/musings:
I know that uWSGI can start as one user and drop into another user role, but I don't really understand this process, so perhaps that's the problem.
uWSGI is trying to access something on the system I'm not aware of
Thanks for your help, I can provide more details if necessary.
EDIT
Oddly, my /var/hpit/log/uwsgi.log file is owned by bsauer:bsauer, not bsauer:www-data or www-data:www-data as I would have expected...
EDIT2
Ok, from looking at http://projects.unbit.it/uwsgi/wiki/Example at the bottom of the page, it looks like the problem is running on port 80. I changed it to 8080, but its still running as bsauer, which I don't think I want.
This is what I came up with as far as I understand it, if anyone wants to put this is clearer sysadmin language I'll be happy to edit.
The solution had nothing to do with the logs after all. The problem was that port 80, the default HTTP port, is protected by the system, and only root can bind to that port. Without sudo, it won't let you bind. Binding to another port, like port 8080, worked fine.
I wanted to bind to port 80 but still run the server as www-data, so I ended up following the very bottom of this page: http://projects.unbit.it/uwsgi/wiki/Example . Basically, the socket to port 80 is shared, and uWSGI can access it first as sudo, and then drop down into www-data to run the server.
I still had to use sudo -E before calling the uWSGI binary, because it needs root permissions to change uWSGI's user and group ID, but it's ok because the end result is the server then runs in the very restricted www-data user.
In the end, my server start line was:
sudo -E /var/hpit/hpit_services/env/bin/uwsgi --shared-socket [::]:80 --http =0 --uid 33 --gid 33 --master --module wsgi --callable app --processes 4 --daemonize ../log/uwsgi.log --pidfile ../server_pid_file.pid
For my current flask deployment, I had to set up a uwsgi server.
This is how I have created the uwsgi daemon:
sudo vim /etc/init/uwsgi.conf
# file: /etc/init/uwsgi.conf
description "uWSGI server"
start on runlevel [2345]
stop on runlevel [!2345]
respawn
exec /myproject/myproject-env/bin/uwsgi --uid www-data --gid www-data --home /myproject/myproject-env/site/F11/Engineering/ --socket /tmp/uwsgi.sock --chmod-socket --module F11 --callable app --pythonpath /myproject/myproject-env/site/F11/Engineering/ -H /myproject/myproject-env
However after running this successfully: sudo start uwsgi
uwsgi start/running, process 1286
And trying to access the application via browser:
I get a 502 Bad Gateway
and an error entry in nginx error.log:
2013/06/13 23:47:28 [error] 743#0: *296 upstream prematurely closed
connection while reading response header from upstream, client:
xx.161.xx.228, server: myproject.com, request: "GET /show_records/2013/6 HTTP/1.1", upstream:
"uwsgi://unix:///tmp/uwsgi.sock:", host: "myproject.com"
But the sock file has the permission it needs:
srw-rw-rw- 1 www-data www-data 0 Jun 13 23:46 /tmp/uwsgi.sock
If I run the exec command from above in the command line as a process, it works perfectly fine. Why is the daemon not working correctly please?
btw Nginx is running as
vim /etc/nginx/nginx.conf
user www-data;
and vim /etc/nginx/sites-available/default
location / {
uwsgi_pass unix:///tmp/uwsgi.sock;
include uwsgi_params;
}
and it is started as sudo service nginx start
I am running this on Ubuntu 12.04 LTS.
I hope I have provided all the necessary data, hope someone can guide me into the right direction. Thanks.
Finally I have solved this problem after working nearly 2 days on it. I hope this solution will help other flask/uwsgi users that are experiencing a similar problem.
I had two major issues that caused this.
1) The best way to find the problems with a daemon is obviously a log file and a cleaner structure.
sudo vim /etc/init/uwsgi.conf
Change the daemon script to the following:
# file: /etc/init/uwsgi.conf
description "uWSGI server"
start on runlevel [2345]
stop on runlevel [!2345]
respawn
exec /home/ubuntu/uwsgi-1.9.12/uwsgi -c /myproject/uwsgi.ini
vim /myproject/uwsgi.ini
[uwsgi]
socket = /tmp/uwsgi.sock
master = true
enable-threads = true
processes = 5
chdir= /myproject/F11/Engineering
module=F11:app
virtualenv = /myproject/myproject-env/
uid = www-data
gid = www-data
logto = /myproject/error.log
This is much cleaner way of setting up the daemon. Also notice the last line how to setup the log file. Initially I had set the log file to /var/log/uwsgi/error.log. After a lot of sweat and tears I realized the daemon is running as www-data and hence can not access the /var/log/uwsgi/error.log since the error.log was owned by root:root. This made the uwsgi fail silently.
I found it much more efficient to just point the log file to my own /myproject, where the daemon has guaranteed access as www-data. And also don't forget to make the whole project accessible to www-data or the daemon will fail with an Internal Server error message. -->
sudo chown www-data:www-data -R /myproject/
Restart uwsgi daemon:
sudo service uwsgi restart
2) Now you have three log files to lookout for:
tail -f /var/log/upstart/uwsgi.log --> Shows problems with your daemon upon start
tail -f /var/log/nginx/error.log --> Shows permission problems when wsgi access is refused, often because /tmp/uwsgi.sock file is owned by root instead of www-data. In that case simply delete the sock file sudo rm /tmp/uwsgi.sock
tail -f /myproject/error.log --> Shows errors thrown by uwsgi in your application
This combination of log files helped me to figure out that I also had a bad import with Flask-Babel in my Flask application. Bad in that sense, that the way I utilized the library was falling back to the system's locale to determine the datetime format.
File "/myproject/F11/Engineering/f11_app/templates/show_records.html", line 25, in block "body"
<td>{{ record.record_date|format_date }}</td>
File "./f11_app/filters.py", line 7, in format_date
day = babel_dates.format_date(value, "EE")
File "/myproject/myproject-env/local/lib/python2.7/site-packages/babel/dates.py", line 459, in format_date
return pattern.apply(date, locale)
File "/myproject/myproject-env/local/lib/python2.7/site-packages/babel/dates.py", line 702, in apply
return self % DateTimeFormat(datetime, locale)
File "/myproject/myproject-env/local/lib/python2.7/site-packages/babel/dates.py", line 699, in __mod__
return self.format % other
File "/myproject/myproject-env/local/lib/python2.7/site-packages/babel/dates.py", line 734, in __getitem__
return self.format_weekday(char, num)
File "/myproject/myproject-env/local/lib/python2.7/site-packages/babel/dates.py", line 821, in format_weekday
return get_day_names(width, context, self.locale)[weekday]
File "/myproject/myproject-env/local/lib/python2.7/site-packages/babel/dates.py", line 69, in get_day_names
return Locale.parse(locale).days[context][width]
AttributeError: 'NoneType' object has no attribute 'days'
This is the way I was using the Flask filter:
import babel.dates as babel_dates
#app.template_filter('format_date')
def format_date(value):
day = babel_dates.format_date(value, "EE")
return '{0} {1}'.format(day.upper(), affix(value.day))
The strangest part is that this code is working perfectly fine within the dev environment (!). It works even fine when running the uwsgi as a root process from the command line. But it fails when ran by the www-data daemon. This must have something to do with how the locale is set, which Flask-Babel is trying to fall back to.
When I changed the import like this, it all worked finally with the daemon:
from flask.ext.babel import format_date
#app.template_filter('format_date1')
def format_date1(value):
day = format_date(value, "EE")
return '{0} {1}'.format(day.upper(), affix(value.day))
Hence be careful when using Eclipse/Aptana Studio that is trying to pick the right namespace for your classes in code. It can really turn ugly.
It is now working perfectly fine as a uwsgi daemon on an Amazon Ec2 (Ubuntu 12.04) since 2 days. I hope this experience helps fellow python developers.
I gave up, there was no uwsgi.log generated, and nginx just kept complaining about :
2014/03/06 01:06:28 [error] 23175#0: *22 upstream prematurely closed connection while reading response header from upstream, client: client.IP, server: my.server.IP, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:/var/web/the_gelatospot/uwsgi.sock:", host: "host.ip"
for every single request. This only happened if running uwsgi as a service, as a process it started fine under any user. So this would work from command line (page responds):
$exec /var/web/the_gelatospot/mez_server.sh
This didn't (/etc/init/site_service.conf):
description "mez sites virtualenv and uwsgi_django" start on runlevel
[2345] stop on runlevel [06] respawn respawn limit 10 5 exec
/var/web/the_gelatospot/mez_server.sh
The process would start but on each request nginx would complain about the closed connection. Strangely I have this same config working just fine for 2 other apps using the same nginx version and same uwsgi version as well as both apps are mezzanine CMS apps. I tried everything I could think of and what was suggested. In the end I switched to gunicorn which works fine:
#!/bin/bash
NAME="the_gelatospot" # Name of the application
DJANGODIR=/var/web/the_gelatospot # Django project directory
SOCKFILE=/var/web/the_gelatospot/gunicorn.sock # we will communicte using this unix socket
USER=ec2-user
GROUP=ec2-user # the user to run as, the group to run as
NUM_WORKERS=3 # how many worker processes should Gunicorn spawn
DJANGO_SETTINGS_MODULE=settings
#DJANGO_SETTINGS_MODULE=the_gelatospot.settings # which settings file should Django use
#DJANGO_WSGI_MODULE=the_gelatospot.wsgi # WSGI module name
DJANGO_WSGI_MODULE=wsgi
echo "Starting $NAME as `the_gelatospot`"
# Activate the virtual environment
cd $DJANGODIR
source ../mez_env/bin/activate
export DJANGO_SETTINGS_MODULE=$DJANGO_SETTINGS_MODULE
export PYTHONPATH=$DJANGODIR:$PYTHONPATH
# Create the run directory if it doesn't exist
RUNDIR=$(dirname $SOCKFILE)
test -d $RUNDIR || mkdir -p $RUNDIR
cd ..
# Start your Django GUnicorn
# Programs meant to be run under supervisor should not daemonize themselves (do not use --daemon)
exec gunicorn -k eventlet ${DJANGO_WSGI_MODULE}:application \
--name $NAME \
--workers $NUM_WORKERS \
--log-level=debug \
--bind=unix:$SOCKFILE
And here is the one that wouldn't work as a service (nginx complaining of prematurely closed connection and no app log data coming through).
#!/bin/bash
DJANGODIR=/var/web/the_gelatospot/ # Django project directory
cd $DJANGODIR
source ../mez_env/bin/activate
uwsgi --ini uwsgi.ini
And the uwsgi.ini:
[uwsgi]
uid = 222
gid = 500
socket = /var/web/the_gelatospot/uwsgi.sock
virtualenv = /var/web/mez_env
chdir = /var/web/the_gelatospot/
wsgi-file = /var/web/the_gelatospot/wsgi.py
pythonpath = ..
env = DJANGO_SETTINGS_MODULE=the_gelatospot.settings
die-on-term = true
master = true
chmod-socket = 666
;experiment using uwsgitop
worker = 1
;gevent = 100
processes = 1
daemonize = /var/log/nginx/uwsgi.log
logto = /var/log/nginx/uwsgi.logi
log-maxsize = 10000000
enable-threads = true
I went from gunicorn to uWSGI last year and I had no issues with it till now, it also seemed a bit faster than gunicorn. Right now I'm thinking of sticking to gunicorn. Its getting better, puts up much nicer numbers with eventlet installed, and it is easier to configure.
Hope this workaround helps. I would still like to know the issue with uWSGI and nginx but I'm stumped.
Update:
So using gunicorn allowed me to run the server as a service and while toying in mezzanine I ran into this error: FileSystemEncodingChanged
To fix this I found the solution here:
https://groups.google.com/forum/#!msg/mezzanine-users/bdln_Y99zQw/9HrhNSKFyZsJ
And I had to modify it a bit since I don't use supervisord, I only use upstart and a shell script. I added this to right before I execute gunicorn in my mez_server.sh file:
export LANG=en_US.UTF-8, LC_ALL=en_US.UTF-8, LC_LANG=en_US.UTF-8
exec gunicorn -k eventlet ${DJANGO_WSGI_MODULE}:application \
--name $NAME \
--workers $NUM_WORKERS \
--log-level=debug \
--bind=unix:$SOCKFILE
I also tried this fix using uWSGI like so ( a lot shorter since using uwsgi.ini ):
export LANG=en_US.UTF-8, LC_ALL=en_US.UTF-8, LC_LANG=en_US.UTF-8
exec uwsgi --ini uwsgi.ini
I am still sticking to gunicorn since it still worked with the problem and lead me in the right direction to resolve it. I was very disappointed that uWSGI provided no output in the log file even with these params, I only seen the server start process and that's it:
daemonize = /var/log/nginx/uwsgi.log
logto = /var/log/nginx/uwsgi.logi
While nginx kept throwing the disconnect error, uWSGI sat there like nothing is happening.
As a single line running with daemon true command is
gunicorn app.wsgi:application -b 127.0.0.1:8000 --daemon
bind your app with 127.0.0.1:8000 and --deamon force it to run as daemon
but define a gunicorn_config.cfg file and run with -c flag is good practice
for more:
https://gunicorn-docs.readthedocs.org/en/develop/configure.html