The information you need to actually useĀ systemctl --user stuff is scattered all over the internet. So let me show you how it works for me, including all the necessary tweaking to actually make it work.

I am using Debian Testing. If you use something else, you might need more or fewer tweaking. In that case: Good luck.

As an example I use an X application: Redshift. X applications are harder to start than non-X apps. This is caused by their need for two environment variables: DISPLAY and XAUTHORITY. More on that later.

First we need to assure that the systemd user stuff is enabled. To check it run systemctl --user status. If it fails, look here.

Now let’s put a redshift.service file into ~/.config/systemd/user
Description=Daemon to adjust display brightness and color temperature to the current time

Wouldn’t it be nice if this just worked? Well it doesn’t. This solution only works for non-graphical applications. So now let’s give the necessary X variables (i.e. DISPLAY and XAUTHORITY) to the program. At many places it is stated that you can put the environment variables into the DefaultEnvironment of the ~/.config/systemd/user.conf file. This didn’t work for me and I don’t know why. This however works:
Description=Daemon to adjust display brightness and redness to the current time

Where the content of /home/username/.config/systemd/xenv is

However on Debian testing this alone still doesn’t do the trick because ~/.Xauthority doesn’t contain the actual cookie. The actual cookie location is varying on restart:

If the above command yields /home/username/.Xauthority for your system, everything should work fine and you don’t need to do the following step.
Put this code in your ~/.profile as suggested here:

    # DISPLAY is set and points to a local display, and XAUTHORITY is
    # set, so merge the contents of `$XAUTHORITY` into ~/.Xauthority.
    XAUTHORITY=~/.Xauthority xauth merge "$XAUTHORITY";;

This copies the X connection credentials to your .Xauthority-file. Note: This may be unsafe if other people can read your home directory.

Now we can actually start our service via systemctl --user start redshift, which is nice. However you may want to start it automatically (“autostart” behaviour). For this you need to add to your “.service” file:

Then you can do systemctl --user enable redshift. It will then be started if you boot to graphical mode and are logged in. Now you can use the whole power of Systemd to observe all your custom user-space daemons, which is nice.

Wrap-Up: You need to do these steps

  1. Assure systemd --user is active
  2. create /home/username/.config/systemd/user/redshift.service with the code from above
  3. create /home/username/.config/systemd/xenv with the environment variables from above (btw: the location for that file is irrelevant, just use the same location in the service file)
  4. add the magic case-statement from above to your /home/username/.profile
  5. systemctl --user enable redshift