Question

我有一个要求，其中一个exec通知另一个exec，它通知一个已定义的资源类型（设置一些变量并运行一个内部exec）。我的理解是，如果第二个exec失败，则不应刷新定义的资源类型。但它确实......请让我知道这里有什么不妥。

`

class test {
Exec  {
path => ['/usr/bin','/sbin','/bin'],
user => 'root',
}
  exec {
    "MAIN":
      command     => 'echo "MAIN EXEC FUNCTION OK"',
      onlyif      => 'test ! -f /var/log/no_file',
      logoutput   => true,
  }
  ~>
  exec {
    "SUB":
      command     => 'echo "SUB EXEC FUNCTION OK"',
      onlyif      => 'test -f /var/log/no_file',
      logoutput   => true,
      refreshonly => true,
  }
  ~>
  res_type {'TITLE':}
}
define  res_type () {
  exec {
    "$title":
      command     => 'echo "EXEC IN DEF RESOURCE TYPE"',
      refreshonly => true,
      logoutput   => true,
  }
}
include test

`

以下是puppet apply run

的输出

puppet apply test.pp
Notice: Compiled catalog for test-server-0 in environment dev in 0.08 seconds
Notice: /Stage[main]/Test/Exec[MAIN]/returns: MAIN EXEC FUNCTION OK
Notice: /Stage[main]/Test/Exec[MAIN]/returns: executed successfully
Notice: /Stage[main]/Test/Exec[SUB]: Triggered 'refresh' from 1 events
Notice: /Stage[main]/Test/Res_type[TITLE]/Exec[TITLE]/returns: EXEC IN DEF RESOURCE TYPE
Notice: /Stage[main]/Test/Res_type[TITLE]/Exec[TITLE]: Triggered 'refresh' from 1 events
Notice: Finished catalog run in 0.64 seconds

`

Answer 1

我的理解是，如果第二个exec失败，则不应刷新定义的资源类型。但它确实......请让我知道这里有什么不妥之处

但第二个Exec 没有失败。它永远不会同步，因为它是refreshonly，因此它不会失败。刷新是一个单独的事情，但是它的命令是否在刷新时执行由相同的标准控制。

此外，即使应用了第二个Exec，它也会失败，这将是非常令人惊讶的。由于command命令的结果而避免运行主onlyif并不构成失败 - 而是Exec已经同步的形式。仅当运行主命令时才会发生故障，并且其退出代码不在被接受为成功的代码中（默认情况下，只接受退出代码0）。

但是，我倾向于说因为Exec从未应用过，所以不应该通知Res_type。由于即使刷新也无法运行命令，因此更不应该通知Res_type。话虽如此，Exec s在事件和刷新方面的行为长期以来一直是一个麻烦的问题，有很多针对各个方面的门票。例如，请参阅与PUP-1106相关的问题列表。

我不认为这种特殊行为是以前票证的主题，所以你可以考虑提交一票，但你可能也应该找到一个更好的方法去做你想做的事情。通常Exec是有利的，有时候它们甚至是合适的，但链接它们会产生温和的代码气味，并且依赖于它们产生的事件具有更强的代码味道。

通过exec条件执行puppet定义的资源类型

1 个答案: