0

I like to keep my custom unit files in their own directory away from /etc. In 247 this worked well, using something like the following:

systemctl enable /path/to/unit.service

This also worked with templates, even those that had an associated timer:

systemctl enable /path/to/timed-unit@.*

After which you would instantiate:

systemctl enable [email protected]

However in 252 when trying to enable the files using pathnames, I now get the following errors:

Failed to enable unit: Destination unit timers.target is a non-template unit.

or:

Failed to enable unit: Destination unit multi-user.target is a non-template unit.

The docs[1] indicate that if a template lists a service (in this case via WantedBys), then it needs a DefaultInstance or instance provided on enabling. This kind of makes sense, so either the behaviour has been tightened up, or a bug has been fixed in 252.

However providing an instance to the path results in a file not found error (as would be expected). I could probably create the symlinks myself, but is there any way to have systemd register a unit file on the filesystem to be enabled with an instance later?

[1] https://www.freedesktop.org/software/systemd/man/systemd.unit.html#%5BInstall%5D%20Section%20Options

2 Answers 2

0

Turns out that the templated units on the filesystem do register, but the error message/output has changed and doesn't confirm so.

So enabling an instance after works as it did before.

0

AFAIK, you should not be able to enable template units, only instance units should be able to be enabled. Because the template itself is not a real unit that can be started on it's self.

You could instead of enabling the template units, which i think you do just so systemd can find the real files by creating symlinks in /etc, try the systemctl link command which is meant especially for that purpose...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .