Issue #22258 has been updated by Eric Badger.
Josh, thanks for the suggestions.
I guess my confusion is coming from the fact that powershell explodes but other
console applications seem to work fine.
I gave the methods you suggested a try, but they didn't fix the problem. Google
has shown me an issue with hanging caused by redirecting powershell's stdin
which suggest similar solutions, but this problem seems to be different.
Having poked at this a bit more, this is my understanding (can't be sure it's
accurate of course): running interactively with 'puppet agent -t' (which uses
ruby.exe in CUI mode) works because there is a real live console there to be
inherited by child processes. Running the service with rubyw.exe works because,
since rubyw.exe uses the GUI subsystem and lacks a console, new consoles are
allocated for each child process. So, if the service (running under ruby.exe)
gets a proper console, that may fix things. This suggested the following to me,
which seems to work:
<pre>
diff --git a/ext/windows/service/daemon.rb b/ext/windows/service/daemon.rb
index 666b11d..93701c2 100755
--- a/ext/windows/service/daemon.rb
+++ b/ext/windows/service/daemon.rb
@@ -55,7 +55,7 @@ class WindowsDaemon < Win32::Daemon
runinterval = 1800
end
- pid = Process.create(:command_line => "\"#{puppet}\" agent --onetime
#{args}").process_id
+ pid = Process.create(:command_line => "\"#{puppet}\" agent --onetime
#{args}", :creation_flags => Process::CREATE_NEW_CONSOLE).process_id
log_debug("Process created: #{pid}")
log_debug("Service waiting for #{runinterval} seconds")
</pre>
Not sure what the side effects of this could be though (nothing broke in my
environment...). Thoughts?
----------------------------------------
Bug #22258: Powershell execs failing when Puppet running as service
https://projects.puppetlabs.com/issues/22258#change-96780
* Author: Eric Badger
* Status: Accepted
* Priority: Normal
* Assignee:
* Category:
* Target version:
* Affected Puppet version: 3.2.3
* Keywords: windows powershell
* Branch:
----------------------------------------
I've just started noticing this on a bunch of machines upgraded to 3.2.3 from
2.7.x, and double checked it on another machine (in a completely separate
environment) that I upgraded from 3.2.1 (no issue in 3.2.1) to 3.2.4.
'exec' resources (both manually and with the powershell provider) that invoke
powershell are failing when run by the puppet service. Error messages like so
are appearing in event logs:
(Here is one pair of events, from Server 2008 R2 upgraded from 3.2.1 to 3.2.4):
<pre>
/Stage[main]/Wintest/Exec[C:\windows\system32\windowspowershell\v1.0\powershell.exe
-ExecutionPolicy Bypass -File C:\guy.ps1]/returns: change from notrun to 0
failed: C:\windows\system32\windowspowershell\v1.0\powershell.exe
-ExecutionPolicy Bypass -File C:\guy.ps1 returned 5 instead of one of [0] </pre>
<pre> C:\windows\system32\windowspowershell\v1.0\powershell.exe
-ExecutionPolicy Bypass -File C:\guy.ps1 returned 5 instead of one of [0] </pre>
(Here is another pair of events, from Win 7 upgraded from 2.7.x to 3.2.3):
<pre>
/Stage[main]/Softwarestat/Exec[C:\Windows\sysnative\WindowsPowershell\v1.0\powershell.exe
-ExecutionPolicy Bypass -File C:\ProgramData\SoftwareStat\init.ps1 -Action
Start -AlwaysCreate]/returns: change from notrun to 0 failed:
C:\Windows\sysnative\WindowsPowershell\v1.0\powershell.exe -ExecutionPolicy
Bypass -File C:\ProgramData\SoftwareStat\init.ps1 -Action Start -AlwaysCreate
returned 2 instead of one of [0] </pre>
<pre>
/Stage[main]/Softwarestat/Exec[C:\Windows\sysnative\WindowsPowershell\v1.0\powershell.exe
-ExecutionPolicy Bypass -File C:\ProgramData\SoftwareStat\init.ps1 -Action
Start -AlwaysCreate]/returns: change from notrun to 0 failed:
C:\Windows\sysnative\WindowsPowershell\v1.0\powershell.exe -ExecutionPolicy
Bypass -File C:\ProgramData\SoftwareStat\init.ps1 -Action Start -AlwaysCreate
returned 2 instead of one of [0] </pre>
Additionally, on the second group of machines, events like these precede the
Puppet events (Windows Error Reporting, id 1001):
<pre> Fault bucket , type 0
Event Name: PowerShell
Response: Not available
Cab Id: 0
Problem signature:
P1: powershell.exe
P2: 6.1.7601.17514
P3: System.ComponentModel.Win32Exception
P4: System.Management.Automation.Host.Host
P5: erShell.ConsoleControl.GetActiveScreenBufferHandle
P6: erShell.ConsoleControl.GetActiveScreenBufferHandle
P7: Consol.. main thread
P8:
P9:
P10:
Attached files:
These files may be available here:
Analysis symbol:
Rechecking for solution: 0
Report Id: 5bdfbad4-0aa4-11e3-8594-001ec935c471
Report Status: 0
</pre>
<pre>
Fault bucket 1734820220, type 5
Event Name: PowerShell
Response: Not available
Cab Id: 0
Problem signature:
P1: powershell.exe
P2: 6.1.7601.17514
P3: System.ComponentModel.Win32Exception
P4: System.Management.Automation.Host.Host
P5: erShell.ConsoleControl.GetActiveScreenBufferHandle
P6: erShell.ConsoleControl.GetActiveScreenBufferHandle
P7: Consol.. main thread
P8:
P9:
P10:
Attached files:
These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\Critical_powershell.exe_4acfe2abd478144236e324a622ef1611d17517_0336da42
Analysis symbol:
Rechecking for solution: 0
Report Id: 398b9517-0a97-11e3-8594-001ec935c471
Report Status: 0
</pre>
No issue occurs if I kick off puppet manually with 'puppet agent -t'. I also
tried kicking off puppet with a scheduled task running as the SYSTEM user
(executing the command 'puppet agent -t' or 'puppet agent --onetime'), which
also worked fine. The issue seems to appear only when the service is starting
the puppet run.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.