fixes#406 because the `tmpfs` mount isn't needed anymore.
Careful considerations had to be taken because #68 mentions host-side
data loss when cleaning up `/tmp`. We mitigate this by ensuring that all
mounts under `/tmp` are unmounted before we proceed with our `rm -rf`
operation.
More context about this issue can be found in #360.
`lxc-info -iH` to retrieve IP address was not available in early LXC
development but was there at LXC 1.0. Because we've bumped our minimum
LXC requirement to v1.0 recently, we can simplify the IP retrieval
process and also get rid of the `dnsmasq` fallback.
The LXC provider issues the "fetch_ip" action to look up the IP address
of the container as part of its "ssh_info" action.
Vagrant::LXC::Action.action_fetch_ip checks the machine state using
Builtin::IsState, which calls Vagrant::Machine.state, which also updates
the state in the machine index and acquires a machine index entry lock to do that.
A race condition ensues in WaitForCommunicator.call, where ready_thr tries
to acquire the machine index lock while running ssh_info, and states_thr tries
to acquire the same lock doing its own state look up (env[:machine].state.id).
If they both try to acquire the lock at the same time, one will fail, and
an exception will be raised.
Work around this issue by checking for the desired machine state (:running) in
Vagrant::LXC::Provider.ssh_info, which can get the state from
Vagrant::LXC::Provider.state, which in turn does not write out the state into
the index file and does not acquire the index entry lock.
This action apparently needs to be added to every provider. See
lib/vagrant/plugins/providers/virtualbox/action.rb from the Vagrant
source for reference how the virtualbox provider is doing it.
Some platforms (most notably CentOS and RHEL) use a kernel without
'attach' support. This patch detects this absence and falls back
to the alternative ways of doing things like detection of IP address
and halting the container.
It does so by running the command "true" through lxc-attach.
