3.2 KiB
| date | draft | math | medium_enabled | medium_post_id | tags | title | |
|---|---|---|---|---|---|---|---|
| 2022-03-15 23:55:19-04:00 | false | false | true | f527d0f12fb8 |
|
Non-Root Systemd Scripts |
I know of two ways to run systemd services not as root. They both have their pros and cons associated with them.
1. Define User/Group
The first method is one I have done before in my docker-compose startup post. It involves adding the User and Group fields to the Service component of the Systemd unit file.
Filename: /etc/systemd/system/docker-compose.service
[Unit]
Description=Docker Compose Application Service
Requires=docker.service
After=docker.service
[Service]
Type=oneshot
User=brandonrozek
Group=brandonrozek
RemainAfterExit=yes
WorkingDirectory=/home/brandonrozek/docker/
ExecStart=/usr/bin/docker-compose up -d
ExecStop=/usr/bin/docker-compose down
TimeoutStartSec=0
[Install]
WantedBy=multi-user.target
You can then start and enable it at boot with
sudo systemctl start docker-compose
sudo systemctl enable docker-compose
2. User-Level Systemd with Lingering Users
An alternative is to have the service file in the user's systemd config directory and add the --user flag during the systemd call.
Filename: /home/brandonrozek/.config/systemd/user/docker-compose.service
[Unit]
Description=Docker Compose Application Service
Requires=docker.service
After=docker.service
[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/home/brandonrozek/docker/
ExecStart=/usr/bin/docker-compose up -d
ExecStop=/usr/bin/docker-compose down
TimeoutStartSec=0
[Install]
WantedBy=multi-user.target
To start and enable:
systemctl --user start docker-compose
systemctl --user enable docker-compose
An issue with this approach as it is right now is that the service will only run while the user is logged in. If you want the service to run despite whether or not the user is logged in, then you'll need to mark the user as lingering.
sudo loginctl enable-linger $USER
You can check if a user already has that property:
sudo loginctl show-user $USER --property Linger
You can even list all users with the linger property:
ls /var/lib/systemd/linger
To disable that property:
sudo loginctl disable-linger $USER
Now what does linger even do?
From FreeDesktop, if linger is enabled for a sepcific user, then a user manager is spawned for that user at boot which handles the user's services and is kept around even after logouts. If linger is not enabled, then a user's services will not start at boot and will stop after the user has no sessions running.
Pros/Cons
For a multi-user system, one can argue that linger is not a good property to have because users can then have a lot of processes spawned and persistent even if they are not using the system. In that case, having an admin individually add systemd unit files using the first approach makes sense.
The second approach has the benefit that the admin only has to set the linger property of the user once, and then the user can create as many systemd unit services as they'd like.