I'm trying to setup gunicorn with systemd for my django project but it fails to load another library of my project.
File "/home/ubuntu/venv/lib/python3.4/importlib/__init__.py", line 109, in import_module
gunicorn[6043]: return _bootstrap._gcd_import(name[level:], package, level)
gunicorn[6043]: ImportError: No module named 'templates'
Templates is another part of the project that is in a separate directory. I would get the same error if I try to run the site without /home/ubuntu/templates/ in my $PYTHONPATH, I've added the pythonpath in my systemd unit file but it didn't do anything.
I can successful run gunicorn with this command:
/home/ubuntu/venv/bin/gunicorn --pid /tmp/pid-gunicorn site_gfa.wsgi:application -b 0.0.0.0:8083
But I fails in systemd
Systemd Unit File
[Unit]
Description="Site"
After=network.target
[Service]
PIDFile=/tmp/pid-gunicorn
User=ubuntu
Group=users
Environment=PYTHONPATH='/home/ubuntu/templates/'
WorkingDirectory=/home/ubuntu/gfa-apps/
ExecStart=/home/ubuntu/venv/bin/gunicorn --pid /tmp/pid-gunicorn site_gfa.wsgi:application -b 0.0.0.0:8083
PrivateTmp=true
Type=forking
[Install]
WantedBy=multi-user.target
I'm running CentOS7 with Python 3.4 and gunicorn 19.4.5
Thanks in advance!
Solved it, the Environment var in systemd unit file shouldn't have quotes around it.
[Unit]
Description="Site"
After=network.target
[Service]
PIDFile=/tmp/pid-gunicorn
User=ubuntu
Group=users
Environment=PYTHONPATH=/home/ubuntu/templates/
WorkingDirectory=/home/ubuntu/gfa-apps/
ExecStart=/home/ubuntu/venv/bin/gunicorn --pid /tmp/pid-gunicorn site_gfa.wsgi:application -b 0.0.0.0:8083
PrivateTmp=true
Type=forking
[Install]
WantedBy=multi-user.target
Related
I've followed this guide (https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-16-04), but I'm presently seeing the following when trying to run gunicorn via the gunicorn service file (/etc/systemd/system/gunicorn.service):
Oct 04 11:30:22 ukgcdeploy01 gunicorn[8095]: File "/opt/envs/automation-console-env/bin/gunicorn", line 5, in <module>
Oct 04 11:30:22 ukgcdeploy01 gunicorn[8095]: from gunicorn.app.wsgiapp import run
Oct 04 11:30:22 ukgcdeploy01 gunicorn[8095]: ModuleNotFoundError: No module named 'gunicorn'
The gunicorn.service file contains the following:
[Unit]
Description=gunicorn daemon
After=network.target
[Service]
User=root
Group=www-data
WorkingDirectory=/opt/envs/automation-console-env
ExecStart=/opt/envs/automation-console-env/bin/gunicorn --timeout 600 --log-level debug --error-log /var/log/automation-console-env_error.log --access-logfile /var/log/automation-console-env_access.log --workers 3 --bind unix:/opt/envs/automation-console-env/automation-console-env.sock django_forms.wsgi:application
[Install]
WantedBy=multi-user.target
Running gunicorn manually works fine:
gunicorn --bind 0.0.0.0:8000 myproject.wsgi
This was previously working before I had to upgrade my Python version from 3.5.2 to 3.9, and due to some issues I ended up having to recreate the virtual environment, so I don't think it's necessarily an issue with the service file, but rather my Python/Gunicorn installation.
If anyone could offer some advice, it would be greatly appreciated :)
Does the automation-console-env environment exist? If so, is gunicorn installed there? In either case, since it is working as gunicorn ... on the command line, you should be able to use this installation.
which gunicorn
Then change your systemd unit file to point to this executable.
It seems that you either are defining the wrong path or you might be facing a permission issue in gunicorn.service.
First try to enable the service by using systemctl enable gunicorn.service. If it didn't work, then try the following:
Edit gunicorn.service as follows:
from: --bind unix:/opt/envs/automation-console-env/automation-console-env.sock django_forms.wsgi:application
to: --bind unix:/opt/envs/automation-console-env/automation-console-env.sock django_forms.wsgi
I am running a virtualenv with Python3.6 on Ubuntu 16.04 for my Django project using uwsgi and NGINX.
I have uWSGI installed globally and also in the virtualenv.
I can run my project from the command line using uWSGI within the env with
/home/user/Env/myproject/bin/uwsgi --http :8080 --home /home/user/Env/myproject --chdir /home/user/myproject/src/myproject -w myproject.wsgi
and go to my domain and it loads fine.
However I am obviously running uWSGI in "Emperor mode" and when I set the service file up (along with NGINX) the domain displays internal server error.
The uWSGI logs trace to --- no python application found ---
I was having this problem when running
uwsgi --http :8080 --home /home/user/Env/myproject --chdir /home/user/myproject/src/myproject -w myproject.wsgi
because it was using the global install uwsgi instead of the virtualenv one.
I changed my StartExec to the virtualenv uwsgi path but no luck.
I can't figure out what I'm doing wrong, path error? Syntax error?
my /etc/systemd/system/uwsgi.service file
[Unit]
Description=uWSGI Emperor service
[Service]
ExecStartPre=/bin/bash -c 'mkdir -p /run/uwsgi; chown user:www-data /run/uwsgi'
ExecStart=/home/user/Env/myproject/bin/uwsgi --emperor /etc/uwsgi/sites
Restart=always
KillSignal=SIGQUIT
Type=notify
NotifyAccess=all
[Install]
WantedBy=multi-user.target
Okay bit silly but it seems I ran sudo systemctl stop uwsgi and then sudo systemctl start uwsgi and it works now.
I use Django-Q for task queue and scheduler. I need to keep running the command: python manage.py qcluster.
How can I do it with Systemd?
I've found this code for .service file but I don't know how to use my Virtualenv for python path:
[Unit]
Description=Async tasks runner
After=network.target remote-fs.target
[Service]
ExecStart=/usr/bin/django-admin qcluster --pythonpath /path/to/project --settings settings
User=apache
Restart=always
[Install]
WantedBy=multi-user.target
Use the django-admin binary installed in your virtualenv's bin directory, or the python binary there to run manage.py within your project's working directory:
ExecStart=/path/to/my-venv/bin/django-admin qcluster --pythonpath /path/to/project --settings settings
or
ExecStart=/path/to/my-venv/bin/python manage.py qcluster --pythonpath /path/to/project --settings settings
RootDirectory=/path/to/project
For those who still have problem with this, Just follow these steps:
create a service, example:
sudo nano /etc/systemd/system/qcluster.service
Edit service as follows:
[Unit]
Description=qcluster runner
After=network.target
[Service]
User=user
WorkingDirectory=/home/user/path_to_project
ExecStart=/home/user/path_to_project_env/bin/python manage.py qcluster
[Install]
WantedBy=multi-user.target
Enable the service:
sudo systemctl enable qcluster.service
Start the service:
sudo systemctl start qcluster.service
I have celery running locally by just running celery -A proj -l info (although I don't even know if I should be using this command in production), and I want to get celery running on my production web server every time nginx starts. The init system is systemd
Create a service file like this celery.service
[Unit]
Description=celery service
After=network.target
[Service]
PIDFile=/run/celery/pid
User=celery
Group=celery
RuntimeDirectory=/path/to/project
WorkingDirectory=/path/to/project
ExecStart=celery -A proj -l info
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s TERM $MAINPID
Restart=on-abort
PrivateTmp=true
[Install]
WantedBy=multi-user.target
Move the file to /etc/systemd/system/ and next time your restart server, celery will be started by systemd on boot.
I have a Python script which I want to run as a daemon. I am doing that by creating a unit file /etc/systemd/system/service
and I want to run it as systemctl start/stop/restart myservice
and depending on this start stop arguments I am handling system signals like SIGUP,SIGINT
Problem is i can run my script as Python main.py start/stop/restart and my logic works.
But after converting into a unit file this python file is invoked by ExecStart and I don't know how to pass arguments there?
[Unit]
Description=This service monitors docker daemon for events
After=multi-user.target
[Service]
Type=simple
ExecStart=/home/PycharmProjects/python_tests/service-discovery/utils/auto_registeration_script/main.py
User=root
WorkingDirectory=/home/PycharmProjects/python_tests/service-discovery/utils/auto_registeration_script/
Restart=on-failure
[Install]
WantedBy=multi-user.target
Isn't it that you are actually running "main.py start" and "main.py stop"? In that case you have programmed a "forking" service.
[Unit]
Description=This service monitors docker daemon for events
After=multi-user.target
[Service]
Type=forking
Environment=script=/home/PycharmProjects/python_tests/service-discovery/utils/auto_registeration_script/main.py
ExecStart=$script start
ExecStop=$script stop
User=root
WorkingDirectory=/home/PycharmProjects/python_tests/service-discovery/utils/auto_registeration_script/
Restart=on-failure
[Install]
WantedBy=multi-user.target