emyl / vagrant-triggers

Allow the definition of arbitrary scripts that will run on the host before and/or after Vagrant commands.
MIT License
546 stars 35 forks source link

Vagrant 1.7.3 subprocess jail can break execution of ruby commands #52

Closed neovatar closed 9 years ago

neovatar commented 9 years ago

I just noticed, that starting with Vagrant 1.7.3 the execution of ruby commands via the vagrant-triggers plugin (and possibly all exeution of external ruby commands) is broken.

When calling a command via vagrant-triggers run, vagrant-triggers takes care to delete GEM_HOME, GEM_PATH and GEMRC from the environment (in https://github.com/emyl/vagrant-triggers/blob/master/lib/vagrant-triggers/dsl.rb#L87), so we can execute ruby commands, that depend on a non vagrant ruby environment.

But vagrant introduced a new "magic" to check if it is executed via bundler, and restores the vagrant environment for the subprocess. So if you call a ruby process, vagrant enforces the old environment and GEM_HOME, GEM_PATH and GEMRC point to the vagrant specific gem locations and things break because gems are not found.

We can set VAGRANT_SKIP_SUBPROCESS_JAILBREAK environment variable to disable the magic, but we need to set it before calling vagrant. Setting it in the Vagrantfile does not seem to work.

https://docs.vagrantup.com/v2/other/environmental-variables.html

VAGRANT_SKIP_SUBPROCESS_JAILBREAK

As of Vagrant 1.7.3, Vagrant tries to intelligently detect if it is running in the installer or running via Bundler. Although not officially supported, Vagrant tries its best to work when executed via Bundler. When Vagrant detects that you have spawned a subprocess that lives outside of Vagrant's installer, Vagrant will do its best to reset the preserved environment dring the subprocess execution.

If Vagrant detects it is running outside of the officially installer, the original environment will always be restored. You can disable this automatic jailbreak by setting the VAGRANT_SKIP_SUBPROCES_JAILBREAK.

I am not sure, how to work around this or how to switch off this behaviour from within the Vagrantfile. It was introduced in Vagrant 1.7.3 (a minor release) and breaks stuff that worked with 1.7.2.

This is not a vagrant-triggers bug, I opened a vagrant bug: https://github.com/mitchellh/vagrant/issues/6242

But maybe @emyl can think of a workaround to make vagrant-triggers with ruby commands work again.

emyl commented 9 years ago

Thomas,

Thanks for the detailed report! I'll investigate on the issue as soon as I can.

neovatar commented 9 years ago

Thanks for the quick response Emiliano! I did some further debugging with vagrant and added some stuff in mitchellh/vagrant#6242.

emyl commented 9 years ago

Fixed! :sunglasses: