puppet-service should be stopped only if file exists - puppet

Question

According to the documentation in my example, the resource 'service x' will be executed if target resource require => Exec['checkForFile'] is successfully applied.
And the exec command will execute onlyif the file '/etc/init.d/x' is present.
so when the file '/etc/init.d/x' is absent,the command in Exec['checkForFile'] should not be executed and
the resource 'service x' should be skipped if target resource is not executed.
For me, the resouce service x is not run which is correct, but at the same time i am not receiving any error or exit code 1 to show Exec['checkForFile'] failed to run. is this expected behavior?
class test2::testcleanup (
$target_location,
)
{
service { 'x':
ensure => stopped,
restart => "service x restart",
stop => "service x stop",
status => "service x status",
require => Exec['checkForFile'],
before => [
File["/etc/init.d/x"],
File[ "remove_directory"],
],
}
exec { "checkForFile":
command => "/bin/true",
path => ["/usr/bin","/usr/sbin", "/bin"],
onlyif => 'test -f /etc/init.d/x',
logoutput => true,
}
file {'/etc/init.d/x':
ensure => absent,
}
file {'remove_directory':
ensure => absent,
path => $target_location,
recurse => true,
purge => true,
force => true,
   }
}

Answer 1

According to the documentation in my example, the resource 'service x'
will be executed if target resource require => Exec['checkForFile'] is
successfully applied. And the exec command will execute onlyif the
file '/etc/init.d/x' is present.
Yes, Service['x'] will not be applied if Exec['checkForFile'] is not successfully applied.
so when the file '/etc/init.d/x' is absent,the command in
Exec['checkForFile'] should not be executed
Yes, but that's different from the Exec not being applied.
Like any other resource, Execs model target-machine state, though in their case, that state is local to the context of one catalog run. Often it is described as whether the Exec's command has been run or not, but it is better characterized the other way around, as whether the Exec's command needs to be run or not. If it is in the "needs to be run" state then successfully executing the Exec's command transitions it to the "does not need to be run" state.
The unless, onlyif, and creates properties of an Exec serve to determine the initial state of the corresponding physical (so to speak) resource. If none of them are provided then the physical resource is initially in the "needs to be run" state. If one or more of them is provided then they may indicate that the Exec initially is in the "does not need to be run" state. And that's the target state. In that case, then, the Exec is successfully applied without running its command.
and the resource 'service
x' should be skipped if target resource is not executed.
No. Service['x'] will be skipped if applying the Exec fails. That happens only if its command is run and exits with a failure status.
For example, instead of using an onlyif in your Exec, use 'test ! -f /etc/init.d/x' as its command.
For me, the resouce service x is not run which is correct, but at the
same time i am not receiving any error or exit code 1 to show
Exec['checkForFile'] failed to run. is this expected behavior?
Maybe.
In your case, the Exec is always successfully applied. If /etc/init.d/x exists then /bin/true is run (successfully). If the file does not exist then the Exec succeeds without running /bin/true. Service['x'] will be applied either way, but if the physical service is already in its target state (stopped), then Puppet won't take any further action, and nothing about that resource will appear in its output at the default log level. Turning on --debug logging in the agent ought to make it clearer what's happening.
But all of that is backward. Puppet is not intended to be a script engine, and it does not work well as one. Any transient machine information needed for determining the appropriate target state for the machine is best conveyed to Puppet in the form of facts. Then you determine during catalog building, based on those facts and any other available data, what resources to declare.
Moreover, it is best to minimize the amount of current machine state that goes into determining its target state. Prefer instead to tie target state to machines' identities, and where necessary, tweak the details based on invariant characteristics (OS, hardware architecture, etc.). Although this model may not be sufficient for all needs, it often does suffice, and it otherwise serves as an excellent baseline.