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](/blog/composesystemd/). It involves adding the `User` and `Group` fields to the `Service` component of the Systemd unit file.
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.
```bash
sudo loginctl enable-linger $USER
```
You can check if a user already has that property:
```bash
sudo loginctl show-user $USER --property Linger
```
You can even list all users with the linger property:
```bash
ls /var/lib/systemd/linger
```
To disable that property:
```bash
sudo loginctl disable-linger $USER
```
Now what does linger even do?
From [FreeDesktop](https://www.freedesktop.org/software/systemd/man/loginctl.html), 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.
