How to enable systemd instantiated service with puppet?

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?

Solution 1:

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.