Running uvicorn as systemd service

Hello,

I would like to start uvicorn at startup with systemd services but for some reason the process exits with an error status=1/FAILURE. This is how my service file looks like:

Description=Uvicorn systemd service.
After=network.target
StartLimitIntervalSec=0

[Service]
Type=notify
ExecStart=/home/username/env/bin/uvicorn myproject.asgi:application --port 8000 --host 11.202.96.136
User=username
Group=username
RuntimeDirectory=/var/run/uvicorn
WorkingDirectory=/var/www/myproject
ExecReload=/bin/kill -s HUP $MAINPID
KillMode=mixed
TimeoutStopSec=5
PrivateTmp=true
RestartSec=1
Restart=always

[Install]
WantedBy=multi-user.target

and the status:

root@ubuntu-2cpu-4gb-de-fra1:/lib/systemd/system# systemctl status uvicorn.service
● uvicorn.service - Uvicorn systemd service.
   Loaded: loaded (/lib/systemd/system/uvicorn.service; enabled; vendor preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Tue 2020-05-19 10:18:25 UTC; 326ms ago
  Process: 847 ExecStart=/home/username/env/bin/uvicorn myproject.asgi:application --port 8000 --host 11.202.96.136 (code=exited, status=1/FAILURE)
 Main PID: 847 (code=exited, status=1/FAILURE)

May 19 10:18:25 ubuntu-2cpu-4gb-de-fra1 systemd[1]: Failed to start Uvicorn systemd service..

What could be the reason behind this error? do you think using supervisor is a better option?

Thank you

[Asday]

Should anyone else turn up here clueless like me, I ended up with the following, where “jingus” is the ficticious name of my project.

/srv/jingus.example.com/conf/jingus.service

[Unit]
Description=Jingus
After=network.target
Requires=postgresql.service

[Service]
Type=simple
User=jingus
Group=jingus
DynamicUser=true

WorkingDirectory=/srv/jingus.example.com/src/src/jingus
PrivateTmp=true

EnvironmentFile=/srv/jingus.example.com/secrets/env

ExecStart=/srv/jingus.example.com/src/env/bin/uvicorn \
        --proxy-headers \
        --forwarded-allow-ips='*' \
        --workers=4 \
        --port=54748 \
        --no-access-log \
        _.asgi:application
ExecReload=/bin/kill -HUP ${MAINPID}
RestartSec=1
Restart=always

[Install]
WantedBy=multi-user.target

• My project is a Django project with the main module named _, hence _.asgi:application;
• access logging is disabled as my reverse proxy does that elsewhere;
• four workers was a number I pulled out of thin air
• the port I chose with this link;
• the reason I’m not using a unix socket is because for some reason uvicorn won’t do multiple workers unless it’s on an INET socket, and setting up something like supervisor or HAProxy for my simple project seemed ridiculous (though if the “some reason” is the stampeding herd, multiple unix sockets with HAProxy is the best way to go);
• using $RUNTIME_DIRECTORY in the unit file never seemed to work so I just wrote everything as an absolute path;
• <...>/src/env/ is a vanilla python virtualenv - heck to poetry, pipenv, and all other such nonsense;
• <...>/secrets/env is a poorly named environment variables file suitable for use with systemd, with 0600 permissions - to use its values for management, try env $(sudo cat ../secrets/env) your_script_that_needs_them;
• my project happens to use postgresql as a backing database, and my server happens to be running it under systemd, hence the entry under [Unit] - of course the correct thing to do is to have the project load and serve a “gimme a moment” page while it waits for the database but that’s not what I did;
• there is PLENTY more to do with regards to sandboxing the process such that it can’t mess with anything it shouldn’t, but again, I’ve not done that.

From there I ran sudo systemctl enable /srv/jingus.example.com/conf/jingus.service

[Asday]

Respectfully I dislike the suggestion to use some chat program instead of issues. I’m here two years later wading through this process myself and there’s nary a mention of systemd in the official docs, nor is the chat program anywhere near useful for this, given it has no search function and is for chatting.

The example given by the good Kinzowa, along with the fix suggested by the good lullis, however, are at the end of a very simple google search.