StopOnIdleEnd was set in the task definition for elevated/privileged
windows guest scripts. This setting:
> specifies that the task stops when the idle condition ceases to be true [1]
The "idle condition" is something that Windows periodically checks for,
and it's defined by a bunch of criteria like user presence/absence, CPU
/ IO idle time, etc. [2]
Telling our provisioner to stop the task if the "idle condition" ceases
to be true is a recipe for some sporadically stopped tasks, which seems
like precisely the behavior being reported in #5362.
I'm pretty sure this fixes#5362
[1] https://msdn.microsoft.com/en-us/library/cc248332.aspx
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa383561%28v=vs.85%29.aspx
In the situation where the SSH key has invalid permissions/owner, the reconnect-loop keeps failing repeatedly yet stays silent about the reasons. A message must be reported from the default exception handler (added). In addition, the situations where the SSH key owner or permissions are wrong must lead to a proper failure (added). Ideally, though, the owner/permissions check must happen before launching the VM, hence this is not a perfect fix.
With this change, any caller of machine.ssh_info is assured that best
efforts will be done to fix possible wrong permissions on the private
key files.
Fix#4652
When the winrm communicator executes a command in an elevated shell,
this patch causes it to escape double quotes.
This is necessary as the first line in the file that it produces and
then executes it puts the command into a variable called command that
is delimited by double quotes.
Command failures include the stdout and stderr in the error message just like the SSH communicator.
Its now possible to specify only an error_class and have that use the correct error_key by default.
Running Windows guest commands through a scheduled task were not returning the correct exit codes, they were only returning 1 or 0. This has negative consequences especially for Puppet which can return an exit code of 2 for partial success.
Since we're running an executable from inside a powershell encoded command we need to ensure we explicitly propagate the exit code to the original caller just like a regular PowerShell script - in this case cmd /c which in return is called from a scheduled task.
Paul Hinze
Max Lincoln
Shawn Neal
Vít Ondruch
Mitchell Hashimoto
Seth Vargo
Peter Ericson
Mitchell Hashimoto
Konstantin Tretyakov
Gilles Cornu
Nicolas Philippe
Leo Simons
Matt Wrock
Stefan Scherer
William E. Triest. III
Richard Guin
jdmulloy