Debian server, uwsgi at boot started by a crontab #reboot.
return this in uwsgi.log:
ile
"/usr/local/lib/python2.7/dist-packages/django/db/backends/postgresql/base.py",
line 175, in get_new_connection
connection = Database.connect(**conn_params) File "/usr/lib/python2.7/dist-packages/psycopg2/init.py", line 164, in
connect
conn = _connect(dsn, connection_factory=connection_factory, async=async) django.db.utils.OperationalError: could not connect to
server: Connection refused Is the server running on host "127.0.0.1"
and accepting TCP/IP connections on port 5432?
Thu Mar 24 05:19:02 2016 - unable to load app 0 (mountpoint='')
(callable not found or import error) Thu Mar 24 05:19:02 2016 - * no
app loaded. going in full dynamic mode Thu Mar 24 05:19:02 2016 -
uWSGI is running in multiple interpreter mode *
if I wait that also postgresql start and restart uwsgi all is working.
Are there way to tell uwsgi to wait for postgresql?
Use systemd to start uWSGI instead of cron daily.
Create file /etc/systemd/system/uwsgi.service with content:
[Unit]
Description=uWSGI
After=syslog.target
After=postgresql#9.4-main.service
Wants=postgresql#9.4-main.service
[Service]
ExecStart=/usr/local/bin/uwsgi --ini /etc/uwsgi/uwsgi.ini
Restart=always
KillSignal=SIGTERM
Type=notify
StandardError=syslog
NotifyAccess=all
[Install]
WantedBy=multi-user.target
Change of course start command for anything you want.
If you want to start more than one uWSGI server (for more than one user perhaps), consider using uWSGI Emperor. You can even create some shared directory in which everyone can create and manage it's own files (by setting sticky bit on directory) and set emperor in tyrant mode, so every vassal will start only from user account that owns specified file, if you want to give anyone ability to create own uWSGI instances.
Related
I'm deploying a website using Django and Django-Channels, with Channel's daphne ASGI server substituting for the typical Gunicorn WSGI setup. Using this Gunicorn WSGI tutorial as a jumping off guide, I attempted to write a systemctl service for my daphne server, when I hit the below error:
CRITICAL Listen failure: [Errno 13] Permission denied: '27646' -> b'/run/daphne.sock.lock'
I was unfortunately unable to find any answers to why permissions would be denied to the .sock file, (in context to Daphne) so I was hoping I could get some hints on where to begin debugging this problem. Below are my daphne.socket and my daphne.service files.
daphne.service
[Unit]
Description=daphne daemon
Requires=daphne.socket
After=network.target
[Service]
User=brianl
Group=www-data
WorkingDirectory=/home/brianl/autoXMD
ExecStart=/home/brianl/autoXMD/env/bin/daphne -u /run/daphne.sock -b 0.0.0.0 -p 8000 autoXMD.asgi:application
[Install]
WantedBy=multi-user.target
daphne.socket
[Unit]
Description=daphne socket
[Socket]
ListenStream=/run/daphne.sock
[Install]
WantedBy=sockets.target
Based off the linked DigitalOcean tutorial, I start my service with sudo systemctl start daphne.socket.
My guess is that there's some kind of discrepancy between setting up systemctl services for Gunicorn and Daphne that I missed, but I don't know for sure.
(If it helps, I'm planning on using Nginx as the main server, but I haven't reached that point yet)
EDIT:
It would help if I also attached the full output systemd gives:
● daphne.service - daphne daemon
Loaded: loaded (/etc/systemd/system/daphne.service; enabled; vendor preset: enabled)
Active: failed (Result: start-limit-hit) since Thu 2019-09-05 22:00:43 UTC; 1min 51s ago
Process: 22041 ExecStart=/home/brianl/autoXMD/env/bin/daphne -u /run/daphne.sock -b 0.0.0.0 -p 8000 autoXMD.asgi:application (code=exited, status=0/SUCCESS)
Main PID: 22041 (code=exited, status=0/SUCCESS)
Sep 05 22:00:43 autoxmd daphne[22041]: warnings.warn('%s. joblib will operate in serial mode' % (e,))
Sep 05 22:00:43 autoxmd daphne[22041]: 2019-09-05 22:00:43,013 INFO Starting server at tcp:port=8000:interface=0.0.0.0, unix:/run/daphne.sock
Sep 05 22:00:43 autoxmd daphne[22041]: 2019-09-05 22:00:43,017 INFO HTTP/2 support not enabled (install the http2 and tls Twisted extras)
Sep 05 22:00:43 autoxmd daphne[22041]: 2019-09-05 22:00:43,020 INFO Configuring endpoint tcp:port=8000:interface=0.0.0.0
Sep 05 22:00:43 autoxmd daphne[22041]: 2019-09-05 22:00:43,022 INFO Listening on TCP address 0.0.0.0:8000
Sep 05 22:00:43 autoxmd daphne[22041]: 2019-09-05 22:00:43,022 INFO Configuring endpoint unix:/run/daphne.sock
Sep 05 22:00:43 autoxmd daphne[22041]: 2019-09-05 22:00:43,022 CRITICAL Listen failure: [Errno 13] Permission denied: '22041' -> b'/run/daphne.sock.lock'
Sep 05 22:00:43 autoxmd systemd[1]: daphne.service: Start request repeated too quickly.
Sep 05 22:00:43 autoxmd systemd[1]: daphne.service: Failed with result 'start-limit-hit'.
Sep 05 22:00:43 autoxmd systemd[1]: Failed to start daphne daemon.
I think this occurred for the permission issue. By default /run directory is owned by root. So the daphne socket failed to create the daphne.sock.lock file in /run directory.
The solution is that create a folder in /run directory and give permission to your user and group.
For example:
sudo mkdir /run/daphne
sudo chown brianl:www-data /run/daphne
Now change the Unix sock path in the service & socket file.
daphne.service
[Unit]
Description=daphne daemon
Requires=daphne.socket
After=network.target
[Service]
User=brianl
Group=www-data
WorkingDirectory=/home/brianl/autoXMD
ExecStart=/home/brianl/autoXMD/env/bin/daphne -u /run/daphne/daphne.sock -b 0.0.0.0 -p 8000 autoXMD.asgi:application
[Install]
WantedBy=multi-user.target
daphne.socket
[Unit]
Description=daphne socket
[Socket]
ListenStream=/run/daphne/daphne.sock
[Install]
WantedBy=sockets.target
Hopefully, this works for you. For further you can go through a similar issue MySQL Daemon Lock issue
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 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.
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
I try to up webserver for django on nginx+uwsgi, os - debian (3.1.0-1-amd64 x86_64)
nginx 1.1.8-1, uwsgi 0.9.8.3-1
configuration:
<uwsgi>
<socket>/tmp/uwsgi.sock</socket>
<process>1</process>
<master/>
<enable-threads/>
<uid>33</uid>
<gid>33</gid>
<pidfile>/tmp/uwsgi.pid</pidfile>
</uwsgi>
in file /etc/uwsgi/apps-enabled/webapp.xml
nginx configuration
location / {
uwsgi_pass unix:///tmp/uwsgi.sock;
include uwsgi_params;
uwsgi_param UWSGI_SCRIPT webapp;
uwsgi_param UWSGI_CHDIR /data/web/webapp/webapp;
}
all projet in /data/web/webapp/webapp/, here setting.py, urls ect.
in /data/web/webapp/webapp/webapp.py
import sys, os
import django.core.handlers.wsgi
sys.path.insert(0, '/data/web/webapp/webapp')
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
application = django.core.handlers.wsgi.WSGIHandler()
uid and gid 33 it is www-data user
try run uwsgi as
root#uwsgi -s /var/run/uwsgi.sock -x
/etc/uwsgi/apps-enabled/webapp.xml
[uWSGI] parsing config file /etc/uwsgi/apps-enabled/webapp.xml
*** Starting uWSGI 0.9.8.3-debian (64bit) on [Wed Dec 14 21:42:02 2011] ***
compiled with version: 4.6.1 on 27 July 2011 18:25:51
writing pidfile to /tmp/uwsgi.pid
uWSGI running as root, you can use --uid/--gid/--chroot options
setgid() to 33
setuid() to 33
your memory page size is 4096 bytes
unlink(): Permission denied [socket.c line 38]
bind(): Address already in use [socket.c line 70]
how permission they want? and what's the problem..
if i run uwsgi as root error is gone, and i see
*** WARNING: you are running uWSGI as root !!! (use the --uid flag) ***
your memory page size is 4096 bytes
uwsgi socket 0 bound to UNIX address /var/run/uwsgi.sock fd 3
uwsgi socket 1 bound to UNIX address /tmp/uwsgi.sock fd 4
your server socket listen backlog is limited to 100 connections
*** Operational MODE: single process ***
*** no app loaded. going in full dynamic mode ***
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 20732)
spawned uWSGI worker 1 (pid: 20733, cores: 1)
but when i try to access the server, ngix returns 502 error page. And more: permission error in nginx logs:
2011/12/14 21:57:17 [crit] 20739#0: *1 connect() to unix:///tmp/uwsgi.sock failed (13: Permission denied) while connecting to upstream, client: 10.10.3.111, server: ******, request: "GET /favicon.ico HTTP/1.1", upstream: "uwsgi://unix:///tmp/uwsgi.sock:", host: "****.****.**"
if change owner of /tmp/uwsgi.sock to nginix user in runtime (www-data), he wrote other logs
[error] 20739#0: *21 upstream prematurely closed connection while reading response header from upstream,
but still error 502 (
how solving this problem? some one can help me..
really want to use nginx+uwsgi instead of apache.
thanks
however, solution is near :)
I use tcp socket now and more, change uwsgi configuration and installed a few more packages.
was an important option --autoload.
now uwsgi has configuration like this:
<uwsgi>
<module>webapp</module>
<socket>127.0.0.1:5080</socket>
<pythonpath>/data/web/webapp/webapp</pythonpath>
<autoload/>
<daemonize>/var/log/uwsgi_webapp.log</daemonize>
<processes>1</processes>
<uid>33</uid>
<gid>33</gid>
<enable-threads/>
<master/>
<harakiri>120</harakiri>
<max-requests>5000</max-requests>
</uwsgi>
remains to solve other problem..
uwsgi use not main system python version >_<
option "pythonpath" found in plugin python26_plugin.so
*** Starting uWSGI 0.9.8.3-debian (64bit) on [Thu Dec 15 22:52:23 2011] ***
compiled with version: 4.6.1 on 27 July 2011 18:25:51
uWSGI running as root, you can use --uid/--gid/--chroot options
setgid() to 33
setuid() to 33
your memory page size is 4096 bytes
*** WARNING: you have enabled harakiri without post buffering. Slow upload could be rejected on post-unbuffered webservers ***
uwsgi socket 0 bound to TCP address 127.0.0.1:5080 fd 4
Python version: 2.6.7 (r267:88850, Aug 3 2011, 12:02:14) [GCC 4.6.1]
Python main interpreter initialized at 0xc47df0
threads support enabled
your server socket listen backlog is limited to 100 connections
*** Operational MODE: single process ***
added /data/web/webapp/webapp/ to pythonpath.
WSGI application 0 (SCRIPT_NAME=) ready on interpreter 0xc47df0 pid: 22983 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 22983)
spawned uWSGI worker 1 (pid: 22984, cores: 1)
he use python 2.6.7 but main system version is 2.7.2 and all python modules installed for this, so a lot of errors in the log - repeated attempts to import non-existent, one of many typical error:
File "/usr/lib/python2.6/dist-packages/django/db/__init__.py", line 78, in <module>
connection = connections[DEFAULT_DB_ALIAS]
File "/usr/lib/python2.6/dist-packages/django/db/utils.py", line 93, in __getitem__
backend = load_backend(db['ENGINE'])
File "/usr/lib/python2.6/dist-packages/django/db/utils.py", line 51, in load_backend
raise ImproperlyConfigured(error_msg)
django.core.exceptions.ImproperlyConfigured: 'django_mongodb_engine' isn't an available database backend.
Try using django.db.backends.XXX, where XXX is one of:
'dummy', 'mysql', 'oracle', 'postgresql', 'postgresql_psycopg2', 'sqlite3'
Error was: No module named django_mongodb_engine.base
so.. how set version of python for uwsgi?
unix sockets must obey to file permission schemes. So /var/run must be writable by www-data and nginx must be able to read/write /var/run/uwsgi.sock
If you are not familiar with this kind of things, you should use tcp sockets (choose a port and you are ready)
how set version of python for uwsgi?
Set option plugins in uwsgi settings:
[uwsgi]
...
plugins = python27
...