11

I've got the following puppet service:

service { "getty@ttyUSB0.service": 
    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[getty@ttyUSB0.service]/enable: change from false to true failed: Could not enable getty@ttyUSB0.service:

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/getty@.service /etc/systemd/system/getty.target.wants/getty@ttyUSB0.service

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?

RASG
  • 222
  • 4
  • 8
Clayton Louden
  • 333
  • 1
  • 4
  • 16

1 Answers1

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 getty@ttyUSB0.service
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.

Dominic Cleal
  • 3,160
  • 19
  • 16