In the process of learning how to deploy a Django webapp using Microsoft’s TFS build + release tools, I came across the need to convert several systemd services that used to be started by root user to systemd user services, so that they could be started and managed by a non-privileged user. Here is one of my original services that is used to run gunicorn (*** designates values that have been redacted):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
[Unit] Description=Gunicorn Service. Server: ***. App: ***. Environment: ***. After=network.target [Service] Restart=always EnvironmentFile=/home/***/env.sh ExecStart=/bin/sh -c '/home/***/env/bin/gunicorn \ --pythonpath /home/***/app/ \ --chdir /home/***/app/ \ --capture-output \ --log-file /home/***/logs/gunicorn.log \ --log-level info \ --pid /home/***/run/gunicorn.pid \ --name *** \ --workers 1 \ --user=*** \ --group=*** \ --bind=unix:///home/***/gunicorn.socket -m 000 \ ***.wsgi' ExecReload=/bin/kill -s HUP $MAINPID ExecStop=/bin/kill -s TERM $MAINPID [Install] WantedBy=multi-user.target |
I ran these steps to convert the original service to a user service:
|
1 2 3 4 5 6 7 |
user@server:~ cd /etc/systemd/system user@server:~ sudo systemctl disable gunicorn.service user@server:~ mkdir -p ~/.config/systemd/user user@server:~ sudo mv gunicorn.service ~/.config/systemd/user/ user@server:~ sudo chown user:user ~/.config/systemd/user/gunicorn.service user@server:~ systemctl --user enable gunicorn.service user@server:~ systemctl --user start |
To my surprise, that worked well and the service has started without complaints. However, I soon discovered two problems:
- The service no longer started automatically after server reboot
- The service only ran when I was SSHed into the server as the user who now managed the service
Turns out, the fix for both issue is relatively straight-forward, once you know what to do, which is the hard part. In order to fix the first problem, I ended up changing the service file:
|
1 2 3 4 |
#[Install] #WantedBy=multi-user.target [Install] WantedBy=default.target |
It turns out that such thing as multi-user.target does not exist for systemd user services, but default.target does.
The second issue was a bit more interesting. Roughly speaking, systemd only runs user services when a user is logged in. When the user logs out, their services are promptly stopped. In order to overcome that, you need to indicate to the login manager that user needs to linger. On Ubuntu 16.04, the command to do so is:
|
1 |
sudo loginctl set-linger username |
After applying both changes and rebooting, my systemd user services where chugging along happily without the need for manual intervention.
