以下Puppet清单用于安装二进制文件和systemd服务描述文件，用于启动作为服务的二进制文件，以及在二进制文件或服务描述更改时重新启动服务。
class my_module::my_service { file { '/usr/local/bin/my_service': notify => Service['my_service'], owner => root, group => root, mode => '500', ensure => present, source => 'puppet:///modules/my_module/my_service', } file { '/lib/systemd/system/my_service.service': notify => Service['my_service'], owner => root, group => root, mode => '400', ensure => present, source => 'puppet:///modules/my_module/my_service.service', } service { 'my_service': require => [ File['/usr/local/bin/my_service'], File['/lib/systemd/system/my_service.service'] ], enable => true, ensure => running, provider => systemd, } } 当我尝试应用它时，我收到以下错误消息：
Warning: /Stage[main]/My_module::My_service/File[/usr/local/bin/my_service]: Skipping because of failed dependencies Notice: /Stage[main]/My_module::My_service/File[/lib/systemd/system/my_service.service]: Dependency User[root] has failures: true Warning: /Stage[main]/My_module::My_service/File[/lib/systemd/system/my_service.service]: Skipping because of failed dependencies Notice: /Stage[main]/My_module::My_service/Service[my_service]: Dependency User[root] has failures: true Warning: /Stage[main]/My_module::My_service/Service[my_service]: Skipping because of failed dependencies
在这个清单中对User[root]的依赖性在哪里出现？我如何解决由此产生的问题？ （在我看来，即使file s的引用引起了对User[root]的隐式依赖，这个特殊的用户在任何情况下都应该已经存在）。
你不能真正避免这种隐含的关系。 您的目录尝试pipe理root用户，如果失败，Puppet将拒绝触摸相关资源。
你应该找出为什么User[root]资源首先失败（当然这是一个主要的红旗），或者如果可能的话，停止pipe理这个资源（pipe理这个账户通常是毫无意义的）。
根本原因是我从一个没有特权的账户运行puppet agent -f 。 添加sudo解决了这个问题。