11

I've got the following puppet service:

service { "[email protected]": provider => systemd, ensure => running, enable => true, }

When I try to apply this configuration on my client, it throws the following error:

err: /Stage[main]//Node[puppetclient]/Service[[email protected]]/enable: change from false to true failed: Could not enable [email protected]:

The service is running fine and I can make sure it's started on system boot by adding a symlink to getty.target.wants:

ln -s /lib/systemd/system/[email protected] /etc/systemd/system/getty.target.wants/[email protected]

Of source, I could go ahead and remove "enable => true" from the service definition and include a the symlink manually in the puppet configuration, but shouldn't puppet take care of this? Am I doing something terribly wrong?

Improve this question

1 Answer 1

Reset to default
8

The systemd provider in Puppet today only uses two commands for the service enable state:

  • systemctl is-enabled <unit>, checking return code for the current enable state
  • systemctl enable/disable <unit> to change it

The enable command throws an error when you enable an instance of the getty@ service that doesn't already exist:

$ sudo systemctl enable [email protected] Failed to issue method call: No such file or directory

This is then causing the error shown in Puppet (though stderr doesn't seem to be displayed).

It looks to me like a gap in systemd that you aren't able to enable new instances of a template. There's already BZ#752774 in Fedora, but the comments suggest it might not be added any time soon.

You might be better off filing a feature request against Puppet to add support specifically for enabling new instances. In your feature request I'd suggest linking to Lennart's explanation of unit instances for background.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.