cannot get systemd [email protected] working

[Ricolette256]

I am on Manjaro-Linux (Arch) and it sits on a btrfs volume. I installed Backrest and let it fetch Restic als dependency. Then I tried several backups manually and everything was nice. But then I wanted to schedule backups and I discovered that I cannot get systemd backrest.service to work. After installation from AUR, I found the systemd Unit which had an unususal file name: [email protected] – Maybe that it is in connection, that I am running btrfs filesystem?

Then I found, that there was no Symlink, pointing to the systemd Unit. I created one manually and started the service manually in the terminal. This brought up an error message of systemd: It refuses to accept the Unit backrest.service.

OK, I looked at the install script on Github, which creates the Unit backrest.service. There are some differencies between the Unit, I got by installing from AUR and the Unit, the Github installer would create.

So I created a new Unit by copying the code from the Github installer and then tried again. But also in this case systemd refused to accept the Unit.

Yesterday there was an update of Backrest in the AUR. This time it created the necessary backrest@service file as a symlink to the systemd unit. But still it did not work.

What can I do, to get backrest.service / systemd to work properly?

[garethgeorge]

Would you mind posting the contents of your systemd service and any errors you're seeing? I don't run arch personally, but I'm particularly curious about why the AUR package might be failing.

This is a community maintained package, not something I maintain personally, but I'd like to look into making it official over time / be sure it stays working.

[Ricolette256]

Hi Gareth,
I am conscious about the fact, that AUR package is not maintained by you or the Backrest team. But as I am not familiar with compiling the software by myself, I prefer to install packages. Also I like, that these packages get updates and I have not to hunt for the next update myself.

Just today a further Update from the Backrest-AUR came in. But the systemd service cannot start after this update.

And yes, within my limits I will support your project by answering your question:

When I tried to start systemd service for backrest by sudo systemctl enable --now backrest@, I got this back:
Failed to enable unit: Refusing to operate on template unit [email protected] when destination unit multi-user.target is a non-template unit

The systemd Unit-file [email protected] contains:
`[Unit]
Description=Backrest Service for %I.
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=%i
Restart=on-failure
Environment=BACKREST_RESTIC_COMMAND=/usr/bin/restic
ExecStart=/usr/bin/backrest

[Install]
WantedBy=multi-user.target`

The systemd unit-file from AUR, which is installed on my machine is:

[Unit]
Description=Backrest Service for %I.
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=%i
Restart=on-failure
Environment=BACKREST_RESTIC_COMMAND=/usr/bin/restic
ExecStart=/usr/bin/backrest

[Install]
WantedBy=multi-user.target

Then I discovered, that the symlink to /usr/lib/systemd/system/[email protected] which is positioned in was incorrect. I renewed this symlink /etc/sytemd/system/backrest@service and tried again to start the service by:
sudo systemctl enable --now backrest@
and then I got:
Failed to enable unit: Refusing to operate on linked unit file [email protected]

OK it seems, that the symlink is wrong here and systemd can run this service without such a symlink. I removed the symlink and tried again and I got again:
Failed to enable unit: Refusing to operate on template unit [email protected] when destination unit multi-user.target is a non-template unit

As I mentioned in my first post, I thought, that the code in this unit may be incorrect. It differs from the code, you show in the installation script on github. So I copied this code of the unit into the file on my machine and tried again. But the result keeps the same.

[Ricolette256]

BTW: it makes no difference, if I try to start the service by ;
`sudo systemctl start [email protected] '

The answer keeps:
'Failed to start [email protected]: Unit name [email protected] is missing the instance name.
See system logs and 'systemctl status [email protected]' for details.
`