-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Elastic-Agent: Do not output to STDERR under powershell, unless you want PS to fail execution as an error #118
Comments
Pinging @elastic/ingest-management (Team:Ingest Management) |
@michalpristas or @blakerouse you know more windows than me. Can you take a look? |
Please note if you don't have |
Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane) |
closing, even with the options set i was not able to repro |
As I document you will not trip this issue in a normal powershell console. This error handling is only on by default in PS Remote, PS ISE and certain ways of scheduling PS scripts. Search for System.Management.Automation.ErrorRecord - If this error handling is enabled any line sent to STDERR becomes an ErrorRecord that needs to be handled. If not you get the NativeCommandError, and with $ErrorActionPreference = "Stop" the exe is stopped/killed.
|
@michalpristas could you please take a look again. |
Problem:
In certain execution contexts PowerShell will convert any line of text sent to STDERR into an Error object. This will no doubt go unhandled thus the commend is failed by powershell:
Google "PS NativeCommandError" to discover all the happy people that trip over this error.
Solution:
On Windows systems (especially under powershell) do not send anything to STDERR unless its really is an error, and the command should be terminated/failed.
Ways to reproduce:
In an Interactive PS, this error handling will most likely not be enabled. Under ISE is most often is.
Open PowerShell ISE and write a ps1 script:
Run the script with the 'play' button in the toolbar (after saving it).
Doing it via ISE like this was the easiest way, I think, to have PS in such an error handling mode. I have experienced the same problem with PS scripts start by the task scheduler.
Extra info:
I maintain scripts to automate starting a demo env.: https://github.com/ElasticSA/ec_spout (more info for Elastic employees here: https://wiki.elastic.co/display/PRES/EC+Spout )
The text was updated successfully, but these errors were encountered: