| If puppet is running in the background as a service, and you run puppet agent -t in the foreground, then the foreground process may not have permission to open the process token for the background process running as LocalSystem resulting in an ugly error message:
c:\Program Files\Puppet Labs\Puppet\puppet\lib\ruby\vendor_ruby\puppet>puppet agent -t --trace |
Error: Could not run Puppet configuration client: OpenProcess(2000, 0, 1604): Access is denied. |
c:/Program Files/Puppet Labs/Puppet/puppet/lib/ruby/vendor_ruby/puppet/util/windows/process.rb:73:in `open_process' |
c:/Program Files/Puppet Labs/Puppet/puppet/lib/ruby/vendor_ruby/puppet/util/windows/process.rb:125:in `get_process_image_name_by_pid' |
c:/Program Files/Puppet Labs/Puppet/puppet/lib/ruby/vendor_ruby/puppet/util/pidlock.rb:69:in `clear_if_stale' |
c:/Program Files/Puppet Labs/Puppet/puppet/lib/ruby/vendor_ruby/puppet/util/pidlock.rb:11:in `locked?' |
c:/Program Files/Puppet Labs/Puppet/puppet/lib/ruby/vendor_ruby/puppet/util/pidlock.rb:20:in `lock' |
c:/Program Files/Puppet Labs/Puppet/puppet/lib/ruby/vendor_ruby/puppet/agent/locker.rb:19:in `lock'
|
Puppet should either interpret that to mean "the pid specified in the lockfile is still running" or it needs to enable the SeDebugPrivilege prior to calling OpenProcess like we do when managing file DACLs. The latter is the only way to detect if the process id is puppet or something else that's now reusing that pid:
with_privilege(SE_DEBUG_PRIVILEGE) do |
open_process(PROCESS_QUERY_INFORMATION, false, pid) do |phandle| |
... |
end |
end
|
|
