You are not logged in.
I'm trying to run per user backup jobs with systemd but it appears not to be reading the local user.conf file. Settings in /etc/systemd/user.conf and /etc/systemd/user.conf.d/user.conf are read (but the /etc/systemd/user/ directory installed by the package is ignored). I'm currently using an EnvironmentFile (not shown) as in the service here, which works fine.
You can use DefaultEnvironment in user.conf, and place that either in
/etc/systemd/user.conf, or in ~/.config/systemd/user.conf
$ cat ~/.config/systemd/user.conf
[Manager]
DefaultEnvironment=ENCRYPTKEY=user.conf LOGS=/backup/logs
$
$ cat ~/.config/systemd/user/duplicity-home.service
[Unit]
Description=Backup Home Directory with Duplicity
After=backup.automount
Requires=backup.automount
[Service]
Type=simple
EnvironmentFile=%h/.config/systemd/user/duplicity.env
# Use either %h or ${HOME} but not in file names because of the /
ExecStart=/usr/bin/duplicity --encrypt-key $ENCRYPTKEY \
--name %H_%u_${JOB1} \
--log-file ${LOGS}/backup_%H_%u_${JOB1}.log \
--exclude %h/.cache \
%h/ file:///backup/%H/%u/${JOB1}
[Install]
WantedBy=duplicity.target
$
$ cat ~/.config/systemd/user/duplicity-home.timer
[Unit]
Description=Backup with Duplicity
[Timer]
OnCalendar=02,05,08,11,14,17,20,23:00:00
;Persistent=true
[Install]
WantedBy=timers.targetAlso, if a variable in DefaultEnvironment is removed, then the last value used is kept, even after systemctl --user daemon-reload.
This is systemd 228. I tried it on OpenSUSE with systemd 210 & it was no better, indeed worse as it didn't take any notice of /etc/systemd/user.conf.d/user.conf
In case it helps anyone else, I had a problem where the timers weren't being enabled after a reboot. This was because of target.wants directories for wrong targets, as here for multi-user.target.wants, which is not a valid user target. That directory dates from an earlier version of the timer and service files and is still there because I changed the target in the unit file without first disabling the unit. Maybe systemctl should check the current target against the new target before changing a unit.
$ ls -rt *
-rw------- 1 test users 66 Feb 7 07:03 duplicity.env
-rw-r--r-- 1 test users 420 Feb 7 21:00 duplicity-home.service
-rw-r--r-- 1 test users 159 Feb 8 04:00 duplicity-home.timer
multi-user.target.wants:
total 0
lrwxrwxrwx 1 test users 52 Feb 7 07:47 duplicity-home.timer -> ~/.config/systemd/user/duplicity-home.timer
lrwxrwxrwx 1 test users 54 Feb 7 07:50 duplicity-home.service -> ~/.config/systemd/user/duplicity-home.service
$To fix this, check that the targets are correct in the unit files, disable each timer and service linked to the wrong target, delete the target.wants directory if necessary then enable them again.
Offline
Is anyone successfully using ~/.config/systemd/user.conf ? Apart from in man systemd.unit, I've only found the ref above and this in the ArchWIki suggesting its use.
For what it's worth, /usr/share/pkgconfig/systemd.pc has only
systemduserconfdir=/etc/systemd/user
Last edited by nobby (2016-02-10 17:05:23)
Offline
I have the same problem. I would like to set some environment variables for my user profile without worrying how i log in to the system (ssh, console, graphical):
% cat ~/.config/systemd/user.conf
[Manager]
DefaultEnvironment="MYVAR=MYVAL"Systemd seems not to pick up this configuration: the command systemctl --user show-environment does not show the configured variable.
Also we seem not to be the only ones having this problem: https://unix.stackexchange.com/question … rminals-or
I also found references for the user.conf file in the user profile from the systemd developers:
Anyone using "~/.config/systemd/user.conf" for setting environment variables?
Offline
From 'man systemd':
Global configuration is done in the directory reported by
pkg-config systemd --variable=systemduserconfdir
$ pkg-config systemd --variable=systemduserconfdir
/etc/systemd/userSo copy the user.conf in this directory.
Offline