Issue #22258 has been updated by Eric Badger.
> Does this mean the powershell module is broken also (without this fix)? That's been my experience. > Currently, the service process (running in cmd.exe), executes ruby.exe, which > executes powershell.exe. All of these are console processes, and because we > are currently using the default creation_flags of 0, each child process > inherits the console of its parent. I think the issue here is caused by > powershell.exe inheriting the console of its grandparent. > Previously, this wasn’t an issue, because the service used to execute > rubyw.exe, which broke the inheritance chain. Makes sense. > Although CREATE_NEW_CONSOLE works, I think it would be preferable to use > DETACHED_PROCESS. They both “work” in that the child does not use the > parent’s console, but in the latter case, the child (and its children) can > never attach to the service’s console. My understanding is that they're pretty much equivalent in this case; while ruby.exe could technically detach from its own console and then attach to the service's console, I don't think there's anything that would actually cause that to happen. And the misbehaving grandchildren (e.g. powershell.exe) won't get access to the service's console through `AttachConsole(ATTACH_PARENT_PROCESS)`, since ruby.exe has its own. Either way, thanks for looking into this. Hopefully a fix makes its way in semi-soon. ---------------------------------------- Bug #22258: Powershell execs failing when Puppet running as service https://projects.puppetlabs.com/issues/22258#change-97167 * Author: Eric Badger * Status: In Topic Branch Pending Review * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: 3.2.3 * Keywords: windows powershell * Branch: https://github.com/puppetlabs/puppet/pull/1861 ---------------------------------------- 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.
