Debian – systemd user service doesn’t autorun on user login

debiansystemd

I have Debian Jessie and connect to it by ssh. I want to autostart shell command on user login by systemd.

I've create a simple systemd service ~/.config/systemd/user/foo.service witch contains:

[Unit]
Description=Systemd autostart test
Wants=local-fs.target
After=local-fs.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo 123 >> /home/user/there;"

[Install]
WantedBy=multi-user.target

I've enable it by systemctl

systemctl --user enable foo

I've created success message container

touch ~/there

and after reboot and login (by ssh) ~/there file is empty.

When I use it manually

systemctl --user restart foo

it works.

What am I missing?

Best Answer

By default, users cannot set user services to run at boot time. The admin must enable this on an individual basis for each user.

sudo loginctl enable-linger <username>

From the documentation:

Enable/disable user lingering for one or more users. If enabled for a specific user, a user manager is spawned for the user at boot and kept around after logouts. This allows users who are not logged in to run long-running services. Takes one or more user names or numeric UIDs as argument. If no argument is specified, enables/disables lingering for the user of the session of the caller.

You also need to set the correct target for WantedBy= as Climenty explained in another answer. The multi-user.target does not exist for user services; by default there is only default.target.

[Install]
WantedBy=default.target

Related Solutions

Systemd – How to Set Environment Variable in Service

Times change and so do best practices.

The current best way to do this is to run systemctl edit myservice, which will create an override file for you or let you edit an existing one.

In normal installations this will create a directory /etc/systemd/system/myservice.service.d, and inside that directory create a file whose name ends in .conf (typically, override.conf), and in this file you can add to or override any part of the unit shipped by the distribution.

For instance, in a file /etc/systemd/system/myservice.service.d/myenv.conf:

[Service]
Environment="SECRET=pGNqduRFkB4K9C2vijOmUDa2kPtUhArN"
Environment="ANOTHER_SECRET=JP8YLOc2bsNlrGuD6LVTq7L36obpjzxd"

Also note that if the directory exists and is empty, your service will be disabled! If you don't intend to put something in the directory, ensure that it does not exist.

For reference, the old way was:

The recommended way to do this is to create a file /etc/sysconfig/myservice which contains your variables, and then load them with EnvironmentFile.

For complete details, see Fedora's documentation on how to write a systemd script.

Systemd: setting dependencies between templated timer units

After thinking that question through a bit, there's an obvious answer: In the clean@.service template, add a dependency on the corresponding backup@.service instance, like this:

[Unit]
After=backup@%i.service

This works fine as long as the services are started in parallel. I don't know right now if services with the same OnCalendar setting are started in parallel are not; I'll update this answer once I've figured that one out.

Best Answer

Related Solutions

Systemd – How to Set Environment Variable in Service

Systemd: setting dependencies between templated timer units

Related Topic