The IsRunning action checks if `env[:machine].state.id == :running` but
this check was never passing as the protobuf-washed version of machine
state was yielding a machine state w/ a string value like `"running"`.
Easy fix in the mapper!
Boolean types (and possibly a few others) are returned as wrapper
classes when coming out from proto mapping; these need to be unwrapped
otherwise the caller who is expecting a nice clean boolean value ends up
with an icky protobuf class.
This fixes the shell provisioner, which relies on a communicator
receiving a settings hash `{error_check: false}` for a command that
usually fails but it sent just in case before provisioning starts.
The local-exec push strategy was assuming it was running from a CLI and
so it wouldn't be a big deal for it to straight up `exec` and replace
its running with the user command. That command will just do its thing
and we want the exit code for the CLI command to match anyways, right?
Sure that works for a shell, but in a GRPC server setting it's decidedly
Not Cool to suddenly swap out the running process!
As you can imagine - the effect of doing this was all sorts of broken
pipes and unexpected EOFs and a very confused @phinze.
Luckily we had a subprocess strategy sitting right there for Windows
compat, so it was just a matter of switching to that in the server
context as well. Long and winding debugging process; simple fix;
just another classic!
When testing all of the push functionality I ran into the fact that the
FTP upload code did not recognize that I had VAGRANT_CWD set, so it
wasn't finding the right files to upload.
This should make everything work properly relative to that location.
VirtualBox introduced a restriction on the valid range for hostonly
networks. When using a version of VirtualBox which includes this
restriction a check is performed on the defined IP address to validate
it is within either the default range (as defined in the VirtualBox
documentation) or the values defined in the network configuration
file.
SLE 11 does not ship systemd and then using systemctl poweroff does not
work. Therefore we fall back to using /sbin/shutdown for machines without
systemd.
This fixes https://github.com/hashicorp/vagrant/issues/12487
We have started seeing occasional shutdown failures on openSUSE Tumbleweed with
Virtualbox inside a qemu virtual machine, where `shutdown -h now` would return
nil. While the machine is successfully turned off, the command fails and vagrant
reports an error.
This commit changes the shutdown command to launch in the background which
also triggers a shutdown, but always succeeds.
