How to write a systemd user service that requires an active session

Question

I've created a systemd user service to run a duplicity backup job once a day at 17:00 broadly based on an article in Fedora Magazine. I'm running Fedora 28 with the Gnome desktop. My systemd timer config is:

[Unit]
Description=daily-backup timer

[Timer]
OnCalendar=*-*-* 17:00:00
Unit=daily-backup.service
Persistent=true

[Install]
WantedBy=default.target

This works well except in the case where the machine was switched off when the backup was due to run. The next time I login, the persistent option ensures the backup runs immediately. Unfortunately the backup script fails at this point because the script tries to run before the user session is active. The backup script starts by trying to mount the backup disk if its not already mounted:

#!/usr/bin/env bash

USER=$(whoami)
MOUNTPOINT="/run/media/$USER/$2"
DEVICE=$(blkid -l -o device -t LABEL="$2")

if [ ! -d "$MOUNTPOINT" ]; then
    gio mount --device $DEVICE
fi

# Call duplicity...

It appears, however, that until the user session is active, the script cannot mount the disk. I can work around this by polling for an active session, but this is a crude solution to the problem:

#!/usr/bin/env bash

USER=$(whoami)
MOUNTPOINT="/run/media/$USER/$2"
DEVICE=$(blkid -l -o device -t LABEL="$2")

# Poll for an active session
for i in {1..30}
do
    SESSION_STATE=$(loginctl show-user "$USER" -p State --value)
    [ "$SESSION_STATE" != "active" ] && sleep 1s || break
done

if [ ! -d "$MOUNTPOINT" ]; then
    gio mount --device $DEVICE
fi

It seems like there should be a way to configure my systemd user service to require an active user session but I've been unable to work out how to do that. Does anyone know if this is possible?

Answer 1

It looks (from the USER=$(whoami) line in your script) that you're running this service as a non-root user (probably by setting User= in your daily-backup.service file.)

You might want to consider setting up the service and timer units as user services, run by the systemd --user manager instead.

To do that, just create daily-backup.service and daily-backup.timer under the ~$USER/.config/systemd/user/ directory. You can essentially use the files you created in the system directory, for the most part unmodified. (You can remove the reference to User= since that will be the user you're setting it up for.)

Use systemctl --user ... commands to enable and start them and to check the status. For the install section, use:

[Install]
WantedBy=default.target

Since the user manager only knows about a default.target (and not e.g. multi-user.target.)

In order to have the user session start at boot, you can enable linger, in which case it will start early and stick around:

loginctl enable-linger $USER

(See documentation for loginctl enable-linger.)

In fact, looking at the Fedora Magazine article you referred to, it seems that's what they had in mind. The "Automate with a timer" part has references to $HOME/.config/systemd/user/.

If you want to read more on systemd user units, the Arch Linux Wiki has a nice article on it.

Answer 2

tl;dr (short answer)

I believe there is no such way, at least out-of-the-box (in form of a systemd unit directive or something). However, this is certainly doable from outside of systemd.

long answer

It would be nice if systemd supported event-based triggering (in a way similar to udev's) or allowed customization of auto-generated unit files. Either idea, if implemented, would solve this problem, but both actually are long-standing shortcomings of systemd.

You may try to implement this logic yourself. If I properly understand what are you trying to actually achieve, you desire the semantics of "delaying" start-up until the session becomes active rather than "skipping" start-up if the session is inactive when the timer triggers.

Then, the basic idea would be to have a daemon that starts as a systemd user service, listens for logind's state change events on the system bus and starts/stops the timer accordingly. This should be easily doable in Python (unfortunately, bash is out of the question because there are no shell-friendly tools that allow listening for signals on D-Bus).